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I. INTRODUCTION 


The Graphics and Video Laboratory of the Department of Computer Science at the 
Naval Postgraduate School permits the researcher to create three-dimensional visual 
simulations from digital terrain data [Ref. 1]. Specialized graphics hardware allows the 
display of such simulations in near-real time. The goal of a good part of the work in the 
lab is the creation of a movie-like view of movement over and on terrain, with 
increasingly complex movement animation models. Such projects have strained the 
equipment’s capabilities. One method of increasing available computing power is to 
hamess multiple heterogeneous machines together in some distributed computing 
organization. It requires communication between the various machines, as well as 


carefully matching each machine's capabilities to its assigned tasks. 


A. PROBLEM 

Rapid turnover of inexperienced students at the Naval Postgraduate School makes 
the creation of complex simulations difficult to manage. The learning curve becomes 
steeper as the lab's capabilities increase. One of the areas of difficulty has been inter- 
computer communications. So much time has been spent on designing, coding, and 
debugging communication software, little has been left for the original research. We set 
out to provide an easy-to-use, yet powerful, set of tools to aid in the development of 
multi-computer projects. 

l. Approach 

A communication protocol can be optimized for large data transfers, or small 

data transfers, or both. Efforts to optimize for both are both complex and difficult 
[Refs. 2,3]. File transfer protocols such as FIP in the Defense Advanced Research 


Project Agency (DARPA) Internet domain and uucp in the UNIX domain can be used for 


large data transfers. Their overhead! is high. This overhead cannot be tolerated in a 


real-time problem?. Our visual simulation efforts rely on small data transfers to 


communicate among machines. These small messages are typically commands and 
changing status indicators. Transferring the entire “world view” is only a reasonable task 
during initialization or reset. Hence, we designed our protocols for small messages. 
2. Design Criteria 

The design criteria for developed protocols were simplicity, ease of use, 
portability, and efficiency. Rapid turnover of inexperienced students at the Naval 
Postgraduate School makes simplicity of paramount importance. Inevitably, changes 
will be required and only a simple protocol is easily modified to take advantage of new 
capabilities. Much the same argument, and generally good software design practice, 
make ease of use only slightly less important. Almost all operating system-level aspects 
are hidden from the application. The number of other machines to be connected to, a use 
of dynamic memory allocation, and the names of the other machines are the only 
concems for the application setting up a connection. The synchronization, or lack 


thereof, in communication between machines is a design decision. 


Portability dictated our use of TCP/IP, an integral part of the Defense Data 
Network (DDN). Efficient use of processor power was considered more important than 
efficient use of the network resources. The network is shared by the entire Computer 


Science Department, but is not heavily loaded. 


! The cost of creating a file and then spawning a process to send it is high. On the receiving end, there is the cost 
of creating the file and then reading it. Even a zero-cost file transfer protocol will require all this overhead. 


? Large data transfers, in real-time systems, will not be possible until 100 MByte/Sec networks are commonly 
available. 


B. BACKGROUND 
1. Visual Simulation 
a. Vision and Information Presentation 
The eye has the largest bandwidth of any human sensory organ. Proper 
use of this capability is a challenge to all scientists. Static graphs are used in most 
disciplines to show the relationships between a limited number of variables. These two- 
dimensional representations convey information more readily to human beings than 


would a table of the underlying numbers. [Ref. 4: pp. 8-12] 


Time, a common independent variable, is often one dimension on a graph. 
The other dimension is a single dependent variable. To portray additional variables in 
one presentation is a frequently occurring requirement. Various techniques such as 
multiple colored lines, multiple icons, and perspective drawing are used. With each 
technique, only a few additional variables are added before the graph becomes 


incomprehensible. 


Pictures, particularly those in color, have a dense information content. 
Unless blind, we live in a world of pictures. Human beings can recognize many 
differences between two similar pictures. One presentation portrays many different 
variables. When a series of pictures are presented, the time variable is easily correlated 
to the actual time of presentation. When a series of pictures is presented rapidly, the 
experience approaches reality, partly explaining the success of moving pictures and 


television. 


Animation creates visual images with an explicit time dimension, in 
addition to two or three spatial dimensions. Using actual time to portray the 
experimental time variable allows at least one more dependent variable on the display. 


Images can be as simple as a changing graph, or as complex as a feature-length cartoon. 


However, animation creates its effect with the playback of prerecorded scenes [Ref. 5]. 
It is not suitable for providing immediate feedback to a researcher. 
b. Definition 
Visual simulation is the creation, by computer, of a realistic, easily- 
modified, moving image from the mathematical model of a phenomenon. Realism 
implies high-resolution, color graphics. Movement implies adequate floating point 
calculation capacity to recalculate the model and its graphical representation between 


display refresh cycles. Easy modification implies a well-designed computer application. 


Visual simulation allows a researcher to experiment easily with his 
subject. Ideally, we display a realistic approximation of part of the world. The 
experimenter then manipulates some part of this visual simulation and receives 
immediate visual feedback. The rapidly refreshed display is one key to visual realism. 
Such a display allows the direct manipulation of the visual simulation, making it easy 
and intuitive to use [Ref. 6]. Ease of use allows the researcher to concentrate on the 
research question, not the display methodology or the computer interface. 

c. Examples 

Recent visual simulation pxojects of the Graphics and Video Laboratory 
include speed control of autonomous vehicles [Ref. 7], control of autonomous walking 
machines [Ref. 8], rule-based control of autonomous underwater vehicles [Ref. 9], 
interactive moving platforms [Ref. 10] and combat vehicle control [Ref. 11]. Each of 
these projects exceeded the capacity of a single workstation. The speed control and 
interactive moving platform projects, written entirely in C, used two Silicon Graphics, 
Inc. IRIS workstations, allowing multiple simultaneous views. The other projects all 
required a rule-based artificial intelligence component, best programmed in Lisp for ease 
of modification. Running the Lisp subsystem on the IRIS workstation gave an 


unacceptably low refresh rate and correspondingly poor realism [Ref. 12]. Placing the 
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Lisp subsystem on another machine improved the refresh rate of the IRIS workstation 
used for the graphics display. 
2. Computer System Architecture 

Computer systems can have a distributed or a non-distributed architecture. 
Distributed architectures have only one characteristic in common, more than one 
processor used to accomplish the task. Beyond this, many different approaches have 
been tried [Ref. 13]. Identical processors give a homogeneous architecture. Different 
processors give a heterogeneous architecture. Either distributed architecture may 
incorporate shared memory or it may not. The separate processors can be closely or 
loosely coupled. Communication between processors can be via shared memory, 
common bus, or some form of communications network. Communication via some 
combination of the above, such as a file server on a local area network, is also 
common [Ref. 3]. In the Computer Science Department at the Naval Postgraduate 
School, a heterogeneous mix of stand-alone workstations, file server supported 


workstation clusters, and minicomputers communicates via Ethernet. 


Programming distributed architectures has inspired creativity. The 
fundamental problems with distributed programming are the communications between 
processes and the temporal interaction of the processes. Communicating sequential 
processes [Ref. 14], distributed processes [Ref. 15], and remote procedure calls 
[Refs. 2,16] have all been proposed as primitives to hide message passing from the 
programmer. Remote procedure calls [Refs. 2,3] and communicating sequential 
processes [Ref. 17] have been implemented. However, even today, none of these is 
generally available as a standard mechanism across varied architectures. We have 
created simpler (but less general) communication routines for use among heterogeneous, 


distributed, standalone computers. 


Complex projects can require the resources of more than one computer. 
Graphics portions are best handled by the specialized hardware of a graphics workstation, 


such as a Silicon Graphics, Inc. IRIS. Artificial intelligence portions are best handled by 


a Lisp machine, such as a Symbolics' or a Texas Instruments Explorer”. Database 


requests can be made to a machine with appropriate database software. A general 


purpose computer, such as the Digital Equipment Corporation VAX'', can be used for 
additional processing power, file storage, or other administrative support. Providing easy 
access across such a mix of heterogeneous computers is a large task [Ref. 3]. The simple 
mechanism described in this work gives communication access between cooperating 
processes running on diverse hardware. It leaves temporal design to the application 
developer, while providing the tools for synchronous and asynchronous interaction. 
3. Communication 

Communications between computers cooperating on a task can be one-to-one, 

many-to-one, or one-to-many. It can be synchronous or asynchronous. Any, or all, of 


these can be required for one visual simulation. 


One-to-one, or direct connect, communications puts the lowest load on the 
network when there are few messages to be sent. A single virtual channel between the 
two processes is required. Each communication between any two processes comprises 
one message. All messages are known to be intended for the receiving process. These 
messages can be sent synchronously or asynchronously. Direct connect communication 


requires one action by the sender and one by the receiver. With more processors, 


" Symbolics is a trademark of Symbolics, Incorporated. 
°° Explorer is a trademark of Texas Instruments Incorporated. 


"°° VAX is a registered trademark of Digital Equipment Corporation 


potential virtual channels grow in number geometrically. For a fully connected network, 
the virtual channels required can exceed capacity. The potential messages required also 


grow geometrically in number. 


One-to-many, or broadcast, communications puts the lowest load on the 
sending process. Á message is sent to all other processes that are connected to it. It 
requires one action by the sender, and two actions by each receiver (the reception and a 
decision on whether the message is intended for that receiver). It also places one to n 
messages on the network (depending on how the network and the broadcast protocols are 
designed). It is primarily used in an asynchronous mode, although synchronous protocols 


could be designed. 


Many-to-one communications puts the highest load on the receiving process. It 
requires two actions by the receiver on every message that is sent by any connected 
process. It is also a primarily asynchronous method. The receiver portion of a process 
sees many-to-one whenever broadcast protocols are the only ones used in a visual 


simulation. 


C. ORGANIZATION 

The previous sections of this chapter provide background on visual simulation, 
distributed architectures, and communication paradigms. Chapter II describes the 
hardware and software environment in the Computer Science Department at the Naval 
Postgraduate School. The protocols developed are discussed in Chapter III. Chapter IV 
describes the implementation of the protocols. Chapter V covers the use of these 
protocols. The performance of the protocols is detailed in Chapter VI. Chapter VII 
concludes with a discussion of limitations, future extensions and research topics, and 
summarizes the research conducted. Listings of the program source code for each of the 


hardware systems are included as Appendices. 


II. EXISTING SYSTEM 


A. INTRODUCTION 
The distributed architecture available in the Naval Postgraduate School Computer 
Science Department Graphics and Video Laboratory is Ethernet-connected workstations 


and minicomputers. The workstations include IRIS 2400, 3120, and 4D graphics, 


Symbolics 36xx" and TI Explorer Lisp, ISI AI, and Sun-3s"*. The minicomputers include 


VAX 11/785 and an ISIV minicomputer complex providing database services. All 


computers, except the Symbolics and TI, use some version of UNIX””” as the primary 


operating system. 


B. HARDWARE 
1. Network 
Ethernet connects all the computers in our lab. There is a backbone network 
and subnetworks for certain groups of computers. Currently there are two subnetworks, 


one for the ISIV minicomputers and one for the ISI AI workstations. Subnetworks are 


planned for the IRIS workstations, the Sun Workstations, and the Symbolics and TI 


workstations. Figure 2.1 illustrates the network configuration. 


" Symbolics 3600, Symbolics 3640, Symbolics 3650, and Symbolics 3675 are trademarks of Symbolics, Inc. 
‘° Sun-3 is a trademark of Sun Microsystems, Inc. 
‘UNIX is a trademark of AT&T Bell Laboratories 
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Sun Workstation is a registered trademark of Sun Microsystems, Inc. 
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Figure 2.1 Network Configuration 





All computers support TCP/IP protocols. The Symbolics Lisp machines also 
use the CHAOS protocol to provide file server services from sym/ to the other Symbolics 
machines. This logical local area network (LAN) uses the Ethernet backbone for its 
messages. The Sun file servers also support their diskless nodes over the backbone 
Ethemet. 

2. Workstations 
a. Silicon Graphics, Inc. IRIS 
Table 2.1 shows the IRIS workstation configurations. All are connected 
directly to the backbone Ethernet. The proprietary Geometry Engines in each of these 
workstations allows three dimensional color graphics displays to be generated and 
updated in real-time. The primary use of these machines is for color graphics. 

b. ISIAI 

Table 2.2 shows the ISI AI workstation configurations. Only aig is 
connected directly to the backbone Ethernet. The other workstations are connected to it 
in a subnetwork. These workstations are used primarily for artificial intelligence 
projects. The aió machine provides, as well as a gateway to the backbone Ethernet, file 
server support for the other workstations. Their high resolution black on white monitors, 


although bitmapped, have rudimentary graphics capabilities. 


Table 2.1 IRIS WORKSTATION CONFIGURATIONS 


Memory Disk i Floating Screen 


No. (MBytes) | Capacity a: Resolution 

4D/70G 1280x1024 
2400 Turbo 1024x768 
3120 1024x768 


4D/70G 1280x1024 
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Table 2.2 ISI AI WORKSTATION CONFIGURATIONS 





c.  Sun-3/50 


Table 2.3 shows the Sun Workstation configurations. All are connected 
directly to the backbone Ethernet. The black-on-white monitors of the Sun diskless 
workstations are primarily used for administrative tasks at this time. 

d. Symbolics 36xx 
Table 2.4 shows the Symbolics workstation configurations. All are 


connected directly to the backbone Ethernet. The Symbolics workstations are used for a 


Screen 
Resolution 
1280x1024 
1280x1024 


1280x1024 


1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 


Table 2.3 SUN WORKSTATION CONFIGURATIONS 


Nickname 


3/180S 
3/50 
3/50 
3/110 
3/110 
3/60 
3/60 
3/60LC 
3/50 
3/50 
3/50 
3/1808 
3/60LC 
3/60LC 
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Screen 
Resolution | 
1280x 1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x 1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 
1280x1024 





Table 2.4 SYMBOLICS WORKSTATION CONFIGURATIONS 


Screen 
Resolution 
1280x1024 


1280x1024 
1024x1024 
| 1280x1024 





variety of research projects involving artificial intelligence. The sym/ machine provides 
file server support for the other Symbolics machines using the Chaos protocol and its one 
GigaByte (unformatted) storage capacity. The color-capable systems are used to display 
static information with color providing an easier human interface. 

e. Texas Instruments Explorer 

Table 2.5 shows the Explorer workstation configurations. All are 
connected directly to the backbone Ethernet. The TJ Explorers are also used for artificial 
intelligence projects. They have the least graphical capabilities of any of the 
workstations. 
3. Digital Equipment Corporation VAX 11/785 

Table 2.6 shows the two DEC' VAX 11/785 computer configurations. Both are 

connected directly to the backbone Ethernet. Only the unix] machine was included in 


this project. The vms? machine may not be available in the future, so the effort to 


Table 2.5 EXPLORER WORKSTATION CONFIGURATIONS 


Screen 
Resolution 
1024x808 


1024x808 
1024x808 
1024x808 





- DEC is a registered trademark of Digital Equipment Corporation 
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Table 2.6 VAX CONFIGURATIONS 

















Operating 


Nickname DSS 
System 


(MBytes) | Capacity 

AT 
vmsl 11/785 1442MB 

develop appropriate code was deemed unnecessary. The unix/ machine is nps-cs.arpa 

on MILNET and is the sole external access point to other machines connected locally via 
Ethemet. It supports the various dial-up lines, as well as other administrative functions. 

4. ISIV minicomputers 

The computers in Table 2.7 make up the ISIV minicomputer complex. Only 

isivó is connected to the backbone Ethernet. The other machines are connected to i5ivó 

in an Ethernet subnetwork. The ISIV minicomputers provide a high performance, multi- 

backend distributed database. Any of the high-resolution black on white monitors can be 

used with any of the hosts on the subnetwork. The character displays can also be used on 


any of the subnetwork hosts. The graphics capabilities of these machines are limited. 


Table 2.7 ISIV DATABASE MACHINE CONFIGURATION 


Screen 
Resolution 
80x24char 
1280x1024 
1280x1024 
1280x1024 
80x24char 
80x24char 
1280x 1024 
1280x1024 
80x24char 


4 
4 
4 
4 
4 
4 
4 
4 
4 
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C. SOFTWARE 
1. UNIX Machines 
Two versions of UNIX are commonly used. The machines purporting to use 
System V', also incorporate characteristics of 4.2BSD and 4.3BSD. The relevant 
incorporation is the Berkeley socket mechanism. 
a. 4.3BSD 
A "pure" 4.3BSD system (4.3 BSD UNIX #11) exists only on unix]. The 
ISIV minicomputers use 4.2 BSD UNIX Release 3.07, with a multi-backend database 
system installed [Refs. 18-20]. The ISI AI workstations use IS68K 4.3 BSD UNIX: 4.0D 
#2. 
b. System V 
The IRIS 4D systems use UNIX System V-based version 4D1-2.2. The 
IRIS 2400 and 3120 systems use UNIX System V-based version GL2-W3.6. Both have 
extensive 4.3BSD extensions. The Sun-3 uses an almost System V version of 4.2BSD 
UNIX. The currently installed release is 3.4. 
2.  Lisp Machines 
a. Genera 
The Symbolics Lisp Machines first used Genera 6.0 software. All 
machines are now on Genera 7.1. 
b. Explorer 
The TI Explorer lisp machine first used Explorer version 1.0.2 software. 


All machines are now on version 3.4 except exp! , which is still on version 3.2. 


' UNIX System V is a trademark of AT&T Bell Laboratories 
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D. SUMMARY 

The configuration described above is constantly changing. Additional machines are 
acquired. Older machines receive hardware upgrades. The network is reconfigured. 
Software releases are updated (especially 4.2BSD UNIX to 4.3BSD UNIX). The 
fundamental needs for distributed computation in this heterogeneous environment 


remain. 
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HI. PROTOCOLS 


A. INTRODUCTION 

Our visual simulation efforts rely on small data transfers to communicate among 
machines. These small messages are typically commands and changing status indicators. 
Hence, we optimized our protocols for small messages. Overhead to optimally encode 
and decode packets was deemed inappropriate. The design criteria for developed 


protocols were simplicity, ease of use, portability, and efficiency. 


B. DIRECT CONNECTION 

The client/server paradigm is used for direct connection. The client requests 
services from the server, so establishing communications is asymmetrical. Once 
communications are established, however, the protocol used is completely symmetrical. 
[Ref. 21: p. 17] 

1. High-Level Protocol 

The variety of data types supported is limited (see Table 3.1). Each message 

contains exactly one instance of one type of data. All integer or float data is converted to 


an ASCII character string before it is sent. It is converted back to the proper type after 


Table 3.1 DATA TYPES SUPPORTED 


( 
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reception. While the conversion is unnecessary when communicating between similar 
architectures, it greatly simplifies the task of communicating between fundamentally 
different architectures. Knowledge of the other machine's architecture is not required. 


The inherent portability of this solution outweighs the processing cost. 


A message is created with three fields. The type field is a one-character field. 
It contains the appropriate code from Table 3.1. The length field is a four-character field. 
It contains an ASCII string from 0001 to 9999. This string gives the length of the dara 
field. The data field is a variable length field containing the ASCII representation of the 


data element. Figure 3.1 illustrates these fields. 


While C programmers are continuously concerned with data types, Lisp 
programmers are not. The Lisp routines support arrays of characters, single integers, and 
single floating point numbers. Each of these is an object. Objects, not types (as implied 


in Table 3.1), are received and sent by lisp applications. The underlying protocol is the 


same, the application interface is different". 


Position 





Figure 3.1 Message Format 


> Chapter 5 discusses applications’ use. 
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2. Supporting Protocols 

Full-duplex stream sockets are used to provide sequenced, reliable connection 
between machines. The sockets are created in the DARPA Internett domain. The 
Internet pseudo-protocol is used [Ref. 22]. No out-of-band capability was included. We 
could not envision a use for it, since our protocol is inherently asynchronous. If a strictly 
synchronous protocol was used, out-of-band transmission might be necessary to interrupt 
for an urgent message. In an asynchronous protocol, however, encoding the next 
message gives the same effect. Processing overhead for encoding is no greater than for 
continuous monitoring for an out-of-band message. With only a small volume of data 


transfers expected, no urgent message waits very long. 


Two ports, each with its own stream socket, are used for each channel between 
machines. Although full-duplex, the stream sockets are used in a simplex mode. The 
separate sockets are used because two processes cannot be bound to the same socket at 
the same time. Two separate UNIX processes then monitor the independent send and 
receive sockets. Blocking sockets are used, avoiding processing overhead for busy- 
waiting. While non-blocking sockets are available in 4.3BSD [Ref. 21: p. 25], they were 
not explicitly available in 4.2BSD [Ref. 22]. Operating systems might include 4.2BSD 
sockets rather than 4.3BSD versions and so the blocking socket mechanism was deemed 


more portable. Both TCP/IP and the C routines provide buffering. 


On the TI Explorer, sockets were also blocking’. Direct access was made to 


the TCP methods provided. Lisp streams are used for the Symbolics lisp routines. The 


* This is the underlying mechanism of the Defense Data Network (DDN) and was chosen for its wide availability 
and applicability to Department of Defense problems. 


? Version 1.0 of the Explorer TCP/IP software uses blocking sockets. Version 2.0 uses non-blocking sockets. 
There has been no update of this system's TI Explorer lisp routines to version 2.0. 
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lisp stream mechanism isolates the code from the issues revolving around blocking 


versus non-blocking sockets. 


C. BROADCAST 


A broadcast message is sent to all machines on a local Ethernet. Those machines 


that are waiting for some broadcast message will probably? receive it. If a machine on a 
subnetwork is to get a broadcast message, an application must run on the gateway 
machine that will rebroadcast on the subnetwork any messages received on the backbone 
Ethernet. Machines not expecting a broadcast message must nevertheless process it and 
reject it as inappropriate. The extra load on all machines connected to the Ethernet 


restricts broadcasting to infrequent occurences until most of the machines used in 


simulations! are on a private subnetwork. 
1. High-Level Protocol 
We expect users of the broadcast protocol to mix its use with the use of direct 
connections. The same data types and messages are supported (see Table 3.1). 
2. Supporting Protocols 
Full-duplex datagram sockets are used to provide connectionless broadcast 
capability. The sockets are created in the DARPA Internet domain. As with our use of 
stream sockets for the direct connection protocol, we use these full-duplex datagram 
sockets in a simplex mode. We use a sending socket for one-way sending of a broadcast 
message to all other machines on a single network or subnetwork. We use a receiving 


socket for one-way receiving from a specific broadcasting machine on the network or 


% Unlike the direct connect protocol, the broadcast protocol does NOT guarantee reception. Trying to provide 
such a guarantee requires a feedback machanism so tliat the sender knows that the machines expected to receive the 
broadcast did so. This is difficult without resorting to a direct connection or flooding the network with messages. 


7 The IRIS machines and the Lisp machines are the ones principally used for visual simulation. 
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subnetwork. Direct connection, with its use of guaranteed reliable stream sockets, is 


used for any other communication, including return messages. [Ref. 21: pp. 32-34] 


As in the direct connection protocol, independent UNIX processes are bound to 


the sockets. Since broadcasting is a one-way activity, a sender or receiver only spawns 


one® UNIX process. 


D. SUMMARY 

By building our high-level protocols on top of DARPA TCP/IP standards, we provide 
the highest degree of portability possible today. By using full-duplex stream sockets and 
datagram sockets in a simplex mode, we do not make full utilization of a socket’s 
capabilities. However, this concer is outweighed by the increased simplicity and 
resultant maintainability of the code. The use of ASCII character strings for the messages 


is simple and makes interconnection with diverse architectures straightforward. 


* [f broadcasting were used exclusively for complete connectivity, each of n machines would spawn n processes. 
If direct connection was used exclusively for complete connectivity, each of n machines would spawn 2n-2 processes. 


20 


IV. IMPLEMENTATIONS 


A. INTRODUCTION 

The first connection was between the IRIS 2400-Turbo and TI Explorer. Then the 
Symbolics Lisp machines were included. These routines have had extensive use 
[Refs. 8,9, 11]. The IRIS functions were updated for the IRIS 4D, coincidentally 
providing Mex support on the older IRIS machines. Broadcast capability was added for 


UNIX-based machines. A port to 4.3BSD UNIX (application calls unchanged) was begun. 


B. SYSTEM V UNIX 
All our System V UNIX-based systems include the socket mechanism first 
introduced by 4.2BSD. Sockets are a key aspect of all implementations. We expect they 
will become part of System V or its successors [Ref. 23]. The System V-unique 
semaphore and shared memory interprocess communication (IPC) capabilities are also 
used. 
1. Silicon Graphics, Inc. IRIS 2400 
a. Sockets 
The socket was introduced in 4.2BSD as the preferred metaphor for IPC. It 
was easy and efficient to implement and the select mechanism could be used to 
implement remote procedure calls, if desired [Ref. 23]. System V had no comparable 


mechanism until version 3 was released with streams. The BSD sockets were included 


by many vendors, Silicon Graphics, Inc. included”. While the use of sockets could be 


? The System V version available on the IRIS machines, at the start of the project, was version 2 and so streams 
were not considered. 
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replaced with streams, device drivers would have to be written. The advantage of 
streams is the ability to filter them between streamhead and the actual device driver. 
These filters, however, reside in the kemel’s address space and have the kernel's 
permissions [Ref. 24]. In our environment, the potential performance increase is not as 


important as the requirement for simplicity. 
The system call for socket creation is socket. The system calls supporting 


socket configuration are setsockopt, bind, connect, and accept? [Ref. 22]. To simplify 
their use, these are all repackaged into four high level routines: connect server and 
connect client for direct connection, start broadcast and broadcast receive for 
broadcast. These routines are encapsulated in netV.c. netV.c can be separately linked 
with any application that needs to make a server/client connection using stream sockets 
or a broadcasting connection using datagram sockets. Table 4.1 describes the four 


routines. 


Using the socket number?! a process can transmit data through the socket. 
In our system, sockets for inter-computer communication are created and used by the 
send and receive processes exclusively. The file netV.c is not linked with the application 


at all. 


'" The accept system call is only relevant to stream sockets. The setsockopt, bind, and connect system calls are 
used with both stream sockets and datagram sockets. 


!! In the direct connect protocol, the server process reads from and writes to a remote socket number. The client 
process reads from and writes to its local socket number. The reason for this is that a server could be connected to dif- 
ferent clients (although not in our implementation) at different times. The client, meanwhile, is only going to connect 
to the one server. In the Internet domain, all necessary routing information, for either server or client, is contained in a 
sockaddr in structure and is accessed (transparently) via the socket number. 

In the broadcast protocol, both the broadcaster and receiver(s) use their local socket number because they are 
using connectionless datagram sockets. The routing information is also contained in a sockaddr. in structure. 
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Table 4.1 


Description 


Creates socket. Binds that 
socket to remote client ad- 
dress and port. Waits to ac- 
cept the remote client con- 
nection. Retums the socket 
number for the remote client. 


Function 


connect_server 


Creates socket. Binds that 
socket to remote server ad- 
dress and port. Connects 
with remote server. Retums 
the local socket number. 


connect. client 


Creates socket. Sets it to 
broadcast mode. Binds it to 
local address and specified 
local port. Retums the local 
socket number. 


start_broadcast 


Creates socket. Binds it to 
local address and specified 
port. Adds broadcaster ad- 
dress and port. Retums the 


broadcast_recelve 


SOCKET SUPPORT FUNCTIONS 


int connect_server( remote_client_name, port_number ) 
char remote client. name[]; 

int port number; 

remote socket —- connect server( remote client name, 


port number ) 


int connect client( remote server name, port number ) 

char remote. server name[]; 

int port number; 

local, socket 2 connect client( remote server name, 
port number ) 

int start broadcast( port number ) 

int port number; 


local socket = start. broadcast( port number ) 


int broadcast receive( broadcaster name, broadcaster port ) 
char broadcaster. name[]; 
int broadcaster port; 


local socket 2 broadcast receive( broadcaster name, 


local socket number. broadcaster port ) 





b. Semaphores 
The semaphore mechanism was chosen as the least expensive, in both 
space and time, for communication between processes. Signals could have been used, 
but implementation would have been more complex and less reliable. Signal-based 
communication functions would also have been more difficult for the application 


programmer to use (Ref. 25: p. 10]. There are two semaphore ids maintained for each 


I One is used to communicate with the send process; one is used to 


connection 
communicate with the receive process. The two semaphores are both used to signal their 


process when it is safe to proceed. A send process is permitted to proceed only after the 


'2 Two semaphore ids are required for direct connect protocol connections since both a send and a receive pro- 
cess are spawned. Two semaphore ids are still created for broadcast protocol connections, even though only one pro- 
cess is spawned. 
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application has requested a write action" on the channel. A receive process is permitted 
to proceed only after the application has read all data from the shared memory buffer. 
Neither the send nor the receive process is executing more than absolutely necessary, 


assuring maximum availability of the local processor to the application. 


The system calls supporting semaphores are semget, semop, and semctl. 
To simplify their use, they are repackaged into three high level routines: semtran, P, and 
V [Ref. 25: pp. 188-190]. These routines (and a support routine semcall) are 
encapsulated in semaphore.c. It can be separately linked with any application that needs 
semaphores. Table 4.2 describes the three routines. 

c. Shared Memory 

A cost barrier to IPC in UNIX is the cost of copying data from one process 
to the kernel and then from the kemel to another process. Using a shared memory 
segment, as a buffer, minimizes this overhead. To further reduce overhead from system 
calls, only a single segment is created. An application accesses the entire segment, while 
a send or receive process accesses only its preassigned section. Figure 4.1 displays the 


layout. The message area of each section is used for several purposes. It is formatted as 


Table 4.2 SEMAPHORE SUPPORT FUNCTIONS 


Function Description 


Creates a semaphore associ- | ìnt semtran( key ) 
semtran ated with a key. Returns a int key; 
semaphore id. sid = semtran( key ); 


ate h void P( sid ) 
cquire sema Ore È s 
1 P int sid; 





void V( sid 
V Release semaphore DR | 
int sid; 


'3 The data must also be valid in the shared memory buffer. All this is transparent to the application, which only 
issues a write command. 
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where n = LARGESTREAD from shared.h 


Figure 4.1 Shared Memory Segment Data Assignment 


a long (4-byte) integer. Table 4.3 describes the meaning of three-state values placed in 


this area. 


Table 4.3 SHARED MEMORY MESSAGES 


Meaning 
to 
receive 


Meaning 
to 
Application 



















send: Data in shared memory 
has not yet been sent to other 
machine. 










Data of length given is 
in shared memory, 
ready to be sent. 


Application has not 
finished reading data 
from shared memory. 






positive 
receive: Valid data of length 
given is in shared meinory, 


ready to be read. 














Application has read 
data from shared 
memory. Message 
from other machine can 
be read, up to LAR- 
GESTREAD bytes. 


negative || Signal to terminate. | Signattoterminate | N/A | 


send: Previous message has 
been sent. Ready to send 
next message. 















Nothing ready to be 
sent. 












receive: No valid data in 
shared memory. 
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The system calls supporting shared memory are shmget, shmat, shmdt, and 
shmctl [Ref. 25: pp. 192-198]. To simplify their use, they are repackaged into four high 
level routines: sharedsegment, dynamicsharedsegment, detachsharedsegment, and 
deletesharedsegment. 'These routines (and a support routine attach within datasegment) 
are encapsulated in shareseg.c. It can be separately linked with any application that 


needs shared memory. Table 4.4 describes the four routines. 


The implementation of shared memory on the IRIS 2400 and IRIS 3120 
was a surprise. A basic UNIX memory allocation scheme is shown in Figure 4.2. Each 
process has its own text, data, and stack sections. Neither the relative locations of these 
sections nor the direction of growth for stack and data sections is specified for UNIX. 
The shared memory segments are logically part of the data section [Ref. 26: p. 151]. 


Table 4.4 SHARED MEMORY SUPPORT FUNCTIONS 


Function 


Creates (if not already in ex- char *sharedsegment( key, nbytes, shmid ) 

istence) a shared memory long key; 

segment associated with a 

key. Attaches application to l 
sharedsegment that shared memory segment. int *shmid; 

Retums a shared memory segment = sharedsegment( key, nbytes, shmid ) 

segment address and id. 

Does not permit subsequent 

dynamic memory allocation. 


long nbytes; 


char *dynamicsharedsegment( nummachines, 


Creates (1f not already in ex- key, nbytes, shmid, freespace ) 


istence) a shared memory 


È ! int nummachines; 
segment associated with a 


key. Attaches application to long key; 

dynamicsharedsegment that shared memory segment. long nbytes; 
Retums a shared memory int *shmid; 
segment address and id. Per- 
mits subsequent dynamic 
memory allocation. 


int freespace; 


segment = dynamicsharedsegment( num- 
machines, key, nbytes, shmid, freespace ) 


s void detachsharedsegment( segment ) 
detachsharedsegment | Detach shared memory seg E i 
ment from application char *segment; 


void deletesharedsegment( segment, shmid ) 
Delete shared memory seg- 


deletesharedsegment 
ment 


char *segment; 


int shmid; 
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growth 
Ss 4 





Figure 4.2 UNIX Memory Allocation 


Actual implementation is left to the team porting UNIX to the machine. The Silicon 


Graphics, Inc. implementation attaches a shared memory segment to the first available 


valid!^ address within the data section. However, the beginning of shared memory 


delimits the size of all other sections [Ref. 26: pp. 367-370]. Figure 4.3 illustrates this 


!4 Shared memory segments must begin on a page boundary. This allows easy table-driven access by multiple 
processes. On the IRIS 2400 and 3120 machines, the Motorola 68000 architecture is used. The pages are 8KBytes. 
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Figure 4.3 IRIS 2400 Default Shared Memory Attachment 


relationship. While no dynamic memory calls! are made, the default arrangement works 
fine. But when dynamic memory allocation—linked lists and makeobj() calls are 


examples—is needed, the technique fails. 


To allow dynamic memory allocation, the shared memory segment must 
be attached at an address beyond the greatest ever required for regular data. Dynamic 
allocation can then occur without reaching the shared memory segment. Attaching at an 
unknown address both within the data section and sufficiently beyond existing data to 
permit dynamic data section growth, can be done at least two ways. First, the data 


section can be expanded until it is as large as possible, then the shared memory segment 


5 Dynamic memory allocation is made with system call brk or altemate sbrk. Library functions malloc, realloc, 
and calloc use brk and so also do dynamic memory allocation. 
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can be attached at a valid location just inside this maximum value. While minimizing 
application programmer effort, this technique requires many system calls to grow the 
data section. It also has the fatal flaw of limiting the stack section, if the stack section 
and data section grow into the same unallocated memory. Second, the NECI can be 


required to prespecify the maximum amount of dynamic memory allocation it might use. 


The solution adopted is adding a freespace parameter to the 
sharedsegment function; and renaming it the dynamicsharedsegment function. The 
sharedsegment function was retained for backward compatibility. The freespace 
parameter gives the caller the ability to specify the maximum additional memory 
required for the application. A request for this additional space is made before the shared 
memory segment is attached. After acquiring (and freeing) the additional space, the next 
available address is determined and the shared memory segment is attached to the next 
valid address. We have now established the shared memory segment beyond the 


specified growth of the application’s data. 


When multiple machines are connected together, there must be a separate 
shared memory buffer for each channel. There is no way to connect a second shared 
memory segment. The solution adopted is adding a nummachines parameter to the 
dynamicsharedsegment function. The nummachines parameter requires the application 
developer to specify, in advance, the maximum number of channels that can be created in 
the application. The first dynamicsharedsegment call establishes a shared memory 
segment big enough for nummachines maximum requested channels. Subsequent 
dynamicsharedsegment calls return the same shared memory id as the first; but retum a 
different address within the segment. Since the application does not directly access these 


functions, there were no problems caused by this parameter list change. 
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The shared memory functions are isolated from the application by the 


machinepath, dynamicmachinepath, dynamicmachinepaths, and  deletemachinepath 


functions!®. For the direct connect protocol, each machinepath, dynamicmachinepath, or 
dynamicmachinepaths call spawns both a send and a receive process. For the broadcast 
protocol, these calls spawn only a send process (for the broadcaster) or a receive process 
(for the receiver). In all cases, the spawned processes issue a sharedsegment call to 
attach to the shared segment earlier created by the spawning function. A command line 
parameter is passed providing the offset into the shared memory segment that the 
spawned process is to use. Figure 4.4 illustrates a system with three machines and two 
channels. 
d. Buffering 

(1) Direct Connect. When a receive process is quiescent, waiting for 
the application to read from the shared memory buffer, anything sent to it is buffered by 
TCP/IP. The buffering provides the reliable delivery promised by a stream socket. The 
next read command will deliver up to LARGESTREAD bytes into the receive data area of 


the shared memory buffer. Since the messages are variable length, there cannot be a 
guarantee that only one message was read!’. Multiple messages might be in the shared 
memory buffer. A partial message might be in the last bytes. 

The shared memory buffer management is handled by the various 


read functions** provided. Each read, requested by the application, is satisfied from the 


16 See Chapter 5, Sections A.1.b(1) and A.1.b(3) for more information on these functions. 

17 The idea to pad all messages to some arbitrary size was considered and rejected. Whatever size was chosen 
would always be too small for some character array. If the maximum Ethernet packet size was chosen, an unnecessary 
network dependence would be introduced. The cost of application buffer management is considered acceptabie, espe- 


cially since it is incurred only on reads. 


18 See Chapter 5, Section A.1.b(2) for more information on these functions 


30 





shared memory buffer 


unallocated 













memory 


—€——— 
= 







unallocated unallocated 


memory memory 


Data Data 


— — -— ss 0 — 0 —Á 00 — 0 -——_—-—— -+-..—  " —_—— n a. r "%41z1-«-«=—2%n»-°l,- -- M M ë O ë M AD ë CND ë amib a ë SEED ë SEED ë SOO ë m 















Application 
| shared nemory buffer n al 


unallocated 


— — n n —"- ’.’ ee 


-— w e —-, = å- e n e å es HA eee —, eee em 


memory 


unallocated unallocated 


Data 


memory memory 






Application 


— — --. o IEEE uu 1 —r—1—-r->-_rr.r._rr" " —"x e M ee ee 


shared memory buffer | 


shared memory buffer 





_— A-— ee O o— ee X" O a AW A A a -— — Do -— 


unallocated 
















memory i 
i 
unallocated unallocated unallocated unallocated 
Data memory memory memory memory 
| Data | Data 


— — — ee -— 


Ethernet _ 
Figure 4.4 Three-Machine Interconnection 





31 


shared memory buffer. Remaining valid data is shifted into the low order positions of the 
data area. The count of valid bytes, held in the message area, is decremented. The 
shared memory buffer now appears as it would have, if it had only received the 
remaining data and not the first message at all. As long as only entire messages are 
received (one or more at a time), this works well. When the TCP/IP buffer has more data 
than the data area can take at one time, however, the receive process deposits 
LARGESTREAD bytes in the shared memory data area. It is highly unlikely that this will 


be on a message boundary. 


A socket read overwrites all data in the data area. A partial data 
reception must be stored and concatenated with bytes from the next socket read to get a 


complete message. The protocol area was introduced to retain the protocol 


information?” required to decipher the variable length messages. The count of already 
received bytes of a message is held here between socket reads. AÀ message's protocol 
information is stored here, too. Protocol information is built up until complete (covering 
the possibility that the break is in the protocol information itself). It is then maintained 


until the entire message is received and read by the application. The buffering works 


with data areas as small as four bytes”, 

(2) Broadcast. The datagram socket used by the broadcast protocol 
preserves message boundaries. Each recvfrom call to a socket returns only one message. 
This message must be no longer than LARGESTREAD bytes. The shared memory buffer 


management routines are not needed. 


I? See Chapter 3, Section B.1 for a description of the protocol 


1% LARGESTREAD must be specified in multiples of four bytes. The smallest possible data area is therefore 
four bytes. 
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TCP/IP keeps unread messages on a queue. This queue may not be in 
sending sequence. If the queue buffer becomes full, subsequent messages are lost 
[Ref. 21: p. 8-8]. The sending buffer can easily be filled if many messages are broadcast 
in a short period of time. Each broadcast message must be processed by SH host on 
the Ethernet. Only then can the next be sent. No access for manipulation of the TCP/IP 
sending buffer is provided because its size is normally specified during system generation 
and is not easily manipulated by an application program. 

2. Silicon Graphics, Inc. IRIS 3120 
There are no required changes to the IRIS 2400-Turbo code. The Makefile 
must be changed to remove the -Zf compile flag, since there is no floating point 
accelerator board in this machine. 
3. Silicon Graphics, Inc. IRIS 4D 
The IRIS 4D required programming changes only to the shared memory 
module, shareseg.c. The path name for user directories is also different. Changes were 


necessary to the Makefile because the /usr/include directory structure changed. 


The IRIS 4D is based on the MIPS RISC architecture. The UNIX 
implementation was done differently than that for the Motorola 68020. Shared memory 
segments are not attached to addresses within the data section, as illustrated in Figure 
4.5. They are attached at a much higher address, yet accessing them does not result in a 
segmentation violation. This is a more robust technique that obviates any manipulation 
of attachment addresses. Multiple shared memory segments are easily attached, using 
default system calls. The sharedsegment call suffices, even when dynamic memory 
allocation is needed. To maintain backward compatibility for application code, 
dynamicsharedsegment calls sharedsegment, ignoring the freespace parameter, when 
compiled on an IRIS 4D, and calls attach within datasegment when compiled on an 


older IRIS machine. 
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Figure 4.5 IRIS 4D Default Shared Memory Attachment 


C. 4.3BSD UNIX 

The netV.c file functions properly on a 4.3BSD machine that is connected to only 
one network. The start_broadcast function does not properly handle multiple networks. 
The other functions work correctly, even when the machine is connected to multiple 


networks. 


All other functions depend upon semaphores and shared memory for 


communication between the spawned processes and the main application. Stream 


sockets”? could be used to provide the IPC between these processes under 4.3BSD. The 


2! Unidirectional stream sockets are equivalent to pipes. 
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three channels” used will have to be multiplexed into one, but the implementation is 


otherwise straightforward. 


D. LISP MACHINES 

The communication code is a flavor to be mixed with the application [Ref. 11]. The 
Explorer software is syntactically equivalent to Genera 6 on the Symbolics. With a 
simple change in the sequence of method and flavor names, the Genera 7 code runs on 
the TI Explorer. The older flavor, originally developed for the Explorer, is also presented 
to illustrate working directly with TCP/IP instead of using a stream. 

1. Texas Instruments Explorer I 

This older flavor works with Release 1.0 of the Explorer TCP/IP software. It 

will not work with Release 2.0 as the implementation was changed from blocking to 


non-blocking [Ref. 27]. 


Messages to the flavors in the ip package are made together with messages to 
the tcp flavors. Network-independent addressing is not used. Table 4.5 describes the 
addressing schemes possible [Ref. 28: pp. 4-2—4-3]. Class C addressing is used by the 
Computer Science Department. Figure 4.6 shows the simple encapsulation of the 


addresses for irisl, iris2, and iris3. Extension to include other machines is easy. 


Table 4.5 INTERNET ADDRESSING CLASSES 


No. 
Networks Hosts 


| B |! 16384) 65536 










2 These are the semaphore, the message areas of the shared memory buffer, and the data areas of the shared 
memory buffer. The first is unidirectional from application to spawned process. The second is bidirectional and three 
state (see Table 4.3). 
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(defvar *irisl-address* 3221866502) 
(defvar *iris2-address* 3221866504) 
(defvar *iris3-address* 3221866505) 


(defvar *dest-address* nil) ; the tcp-ip or internet address 


; look in network configuration 


(defun iris (x) 
(cond ((equai x l) (setq *dest-address* *irisl-address*)) 
((equal x 3) (setq *dest-address* *iris3-address*)) 
(t (setq *dest-address* *irisZ-address*)) ) ) 


Figure 4.6 Encapsulation of IRIS Addresses 


A port is acquired by using the :get-port method of the tcp-handler flavor. 
Here, shown in Figure 4.7, we use the global instance, *tcp-handler*^ to create specific 
instances of the Transmission Control Block (TCB) for each of the two ports. Only the 
client side of the server/client paradigm has been implemented. The client is created by 
using the :active mode argument to the :open method of the tcp-port flavor. Both the 
sending and receiving ports are full duplex, but are only used in a simplex mode. Figure 


4.8 shows the creation of the sending port [Ref. 28: pp. 4-12—4-18]. 


The three fields in a message are sent and received separately. Each field is 
then treated as a separate object. Figure 4.9 illustrates sending a message. For all fields, 


the urgent argument is specified as nil. The push argument is specified as nil until the 


(defvar *tcp-handlerl* (send ip::*tcp-handler* :get-port)) 
(de fvar *tcp-handler2* (send ip::*tcp-landler* :get-port)) 


Figure 4.7  Lisp Port Acquisition 


23 The double : allows the tcp-handler to be found, since it was not created "exportable" in the ip package. 
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(send talking-port :open 
:active ; tcp will begin the procedure to establish 
; connection (default vs :passive) 
talking-por t -number ; port number of destination host . 
destination : machine mame or address if blank aud 
; in :passive niode local machine waits for 
> connection 
30 ) ; set max seconds before read request times out 


Figure 4.8 Opening a Lisp Client Connection 


(progn 
(send talking-port :send 
typebuffer 
1 
nil 
nil ) 


(if (= (length lengthbuffer) 4) 
(send talking-port :send 
lengthbuffer 
4 
nil 
nil ) 
(progn 
(loopfor *loopvariable* (length lengthbuffer) 4 
(send talking-port :send "O" 1 nil nil) ) 
(send talking-port :send lengthbuffer (length lengthbuffer) nil nil) ) ) 
(send talking-port :send 
buffer 
buffer-length 
t 
nil ) ) 


Figure 4.9 Sending a Message 


data buffer is sent, when it is specified as t. The entire message is thus sent as a unit to 
the other machine. 
2. Symbolics 36xx 
Genera 7 syntactic conventions are followed. The principle difference with 
Genera 6 conventions is in the defmethod function. In Genera 6 (and the TI Explorer), 


the method name follows the flavor name. In Genera 7, the method name precedes the 
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flavor name. Figure 4.10 shows the difference. It also shows the other main difference 


with the earlier code, that streams are used. The use of streams improves portability and 


eliminates the need for the :reuse-iris method^*. It may be slightly slower, but any 


difference has been unnoticeable. 


Another change was to remove the dependence on hard-coded addresses. The 
method :init-destination-host was added to the conversation-with-iris flavor (see 
Figure 4.11). By using the net:parse-host function, the application need only know the 
name of another machine. As network tables are updated, no change to the application 


code is necessary unless a different machine is desired. 


(defmethod (conversation-with-iris :stop-iris) 


() 
(progn (send talking-port :close) 
(send listening-port :close) ) ) 


Genera 6 
(defmethod (:stop-iris conversation-with-iris) 
() 


(progn (send talking-stream :close) 
(send listening-stream :close) ) ) 


Genera 7 
Figure 4.10 Genera 6 and 7 defmethod 


(defmethod (:init-destination-host conversation-with-iris) 
(name-of-host) 
(setf destination-host-object (net:parse-host name-of-host)) ) 


Figure 4.11 Generic Host Addressing 


24 The :reuse-iris method is retained for backward compatibility. 
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E. SUMMARY 

For UNIX-based machines, generic routines are developed for semaphore use, 
shared memory use, and socket use. The socket routines use both stream sockets and 
datagram sockets in a simplex mode to provide directly connected ino and 
unconnected broadcasting communications. IRIS 2400, 3120, and 4D systems are fully 


supported. 4.3BSD systems are supported with mid-level socket calls only. 


For Lisp machines, stream-based functions are available for direct connection as 
clients only. These functions are available directly if using Genera 7 syntax and with 


minor modification if using Genera 6 syntax. 
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V. USE BY APPLICATIONS 


A. INTRODUCTION 

The application using either direct connect or broadcast protocol is not concerned 
with system-level implementation details. Almost all aspects of shared memory, 
semaphore, and socket use are hidden. The number of other machines to be connected 
to, the use of dynamic memory allocation, and the names of the other machines are all 
that concern the application in setting up a connection. The synchronization, or lack 
thereof, in communication between machines is a design decision, not a protocol 


decision. 


B. DIRECT CONNECT 
A UNIX-based machine can be either a server, waiting for a client to call and 
establish a connection, or the client. A Lisp machine is always a client. 
1l. UNIX-Based Machines 
The functions provided for UNIX-based machines are all written in C. They 
must be linked into the application program using them. Figure 5.1 is an example make 


file for creation of an application program on an IRIS system. 
There are two independent processes, send and receive, that are spawned to 


create the sockets and monitor them. They are made separately with the makefile” 


contained in their subdirectory. 


5 See Appendix A 
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o —1—rr "me ___é“‘0O_\@0 O 

CFLAGS = -Zg -im -g -p 

SHARE = /work/barrow/share3/ 

MAIN =  carsimu.c 

OBJS = First group of .o files 

OBJS1 = Second group of .o files 

OBJS2 = Third group of .o files 

OBJS3 = $(SHARE)io_single.o \ 
$(SHARE)mpath.o \ 
$(SHARE)semaphore.o \ 
$(SHARE)shareseg.o \ 
$(SHARE) support.o 

OBJS4 = Fifth group of .o files 


carsimu: $(MAIN) $(OBJS) $(OBJS1) $(OBJS2) $(OBJS3) $(OBJS4) 
cc -o carsimu $(MAIN) $(OBJS) $(OBJS1) $(OBJS2) $(OBJS3) $(OBJS4) $(CFLAGS) -ibsd 


$(MAIN): const.h vars.h 
$(OBJS): const.h vars.h 
$(OBJS1): const.h objects.h 
$(OBJS2): const.h 


$(SHARE)mpath.o: $(SHARE)shared.h 
cc -c -o $(SHARE)mpath.o $(SHARE)mpath.c $(CFLAGS) 


$(SHARE)support.o: $(SHARE)shared.h 
cc -c -0 $(SHARE)support.o $(SHARE)support.c $(CFLAGS) 


$(SHARE) semaphore.o: 
cc -c -0 $(SHARE)semaphore.o $(SHARE)semaphore.c $(CFLAGS) 


$(SHARE)io_single.o: $(SHARE)shared.h 
cc -c -o $(SHARE)io_single.o $(SHARE)io_single.c $(CFLAGS) 


$(SHARE) shareseg.o: 
cc -c -o $(SHARE)shareseg.o $(SHARE)shareseg.c $(CFLAGS) 


Figure 5.1 Sample Application make File 


a. Application Setup 
The server process must be started first. The application can set up the 


communications paths as part of initialization, or it can do so only in response to a 
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specific operator command. In either case, there will be two messages returned to the 
terminal for each direct connection setup. Figure 5.2 illustrates a normal, single 
connection, response. Since the receive and send processes that provide the messages 
are independent, the two lines shown may be jumbled. A variety of errors can occur at 


this point. Table 5.1 gives the most common error messages, their cause, and solution. 


Server waiting to connect to name 
Server waiting to connect to name 


Figure 5.2 Normal Server Response 


Table 5.1 SERVER ERROR RESPONSES 


Message 


Server couldn't open a local socket: 


Server couldn't bind address to local socket: 


shmget: Permission denied 


shmget: Invalid argument | 


shmat: Permission denied 


Socket in use due to previ- 
ous run not terminating 
with deletemachinepath 


Socket in use due to previ- 
ous run not terminating 
with deletemachinepath 


The shared memory seg- 
ment already exists, but is 
owned by another uid 


The shared memory seg- 
ment already exists, but is 
too smali because the value 
of LARGESTREAD has 
been increased 


Someone else’s send or re- 
ceive process is being 
spawned 


Outdated software is being 
used. 
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Solution 


Run ps. Use kill to ter- 
minate any receive or send 
processes still running 


Run ps. Use kill to ter- 
minate any receive or send 
processes still running 
Change key in 
maclinepath call, recom- 
pile, and rerun 


Run rmshare and rerun ap- 
plication 


Check that proper path is 
used in shared, for 
application’s include of 
shared.li, and in 
application’s Makefile. 
Correct and recompile. 
Ensure that all modules are 
the most current. If some 
are not, get updated 
modules and recompile— 
especially send and re- 
ceive. 





The client process must not attempt connection until after the server is 
properly running (the messages in Figure 5.2 have been received). The application can 
set up the communications paths as part of initialization, or it can do so only in response 
to a specific operator command. When client communications setup is part of the 
initialization, care must be taken to wait for a ready server before starting the client. In 
either case, there will be two messages returned to the terminal for each direct 
connection setup. Figure 5.3 illustrates a normal, single connection, response. Since the 
receive and send processes that provide the messages are independent, the two lines 
shown may be jumbled. A variety of errors can occur at this point. Table 5.2 gives the 
most common error messages, their cause, and solution. 

b. Coding Practices 

(1) Connection. Making a connection requires two acts. The first is to 
set aside space for the data required. Figure 5.4 shows this code when local declaration 
is used. The Machine structure can also be declared globally. The second is to request 
the connection with a machinepath, dynamicmachinepath, or dynamicmachinepaths 
call. Table 5.3 compares the three types of call, while Figure 5.5 gives a server example 
for dynamicmachinepath. A description of the parameters used is in Appendix A, 


Section 2.a. 


For flexibility, there is often a requirement for command line 


specification of the machine to be connected to. For ease of use, there is often a 


Connection established with name 
Connection established with name 


Figure 5.3 Normal Client Response 
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Client couldn't open a local socket: 


Client couldn't connect to the remote server socket: 


shmget: Permission denied 


shmget: Invalid argument 


shmat: Permission denied 


Table 5.2 CLIENT ERROR RESPONSES 


Socket in use due to previ- 
ous run not terminating 
with deleteniachinepath 


The server has not success- 
fully started 


The port numbers used by 
client do not correspond to 
those of server 


The shared memory seg- 
ment already exists, but is 
owned by another uid 


The shared memory seg- 
ment already exists, but is 
too small because the value 


of LARGESTREAD has 


been increased 


Someone else's send or re- 
ceive process is being 
spawned 


Outdated software is being 
used. 


Solution 
Run ps. Use kill to ter- 


minate any receive or send 
processes still running 


Terminate client, restart 


server, restart client when 
server started 


Correct, recompile, and 
rerun 


Change key in 
machinepath call, recom- 


pile, and rerun 


Run rmshare and rerun ap- 
plication 


Check that proper path is 
used in sharedh, for 
application’s include of 
shared.h, and in 
application’s Makefile. 
Correct and recompile. 

Ensure that all modules are 
the most current. If some 
are not, get updated 
modules and recompile— 
especially send and re- 


cetve. 





#include "/work/barrow/share3/shared.h" 
main(argc,argv) 


[IIAAIAAI AIA AIA AAAAA AA AAA AAIA AIA IAA AAA ARIA AAA ARIA A AIA AAA AI 


LOCAL DECLARATIONS 


Ae e a e ake ae e ale ae Ae e Ake ahe ake ake akeke de ek ke e e oheak ke ak ERE EERE EEE EEE EEE RR RE DM 
Machine cardriver; /* structure for conmunications system */ 


Figure 5.4 Creation of Machine Structure 
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Table 5.3 PATH CONNECTION 


Function 


Creates a link between two machines 


machinepath No subsequent dynamic memory allocation al- 
lowed 


Creates a link between two machines 
dynamicmachinepath 
Subsequent dynamic memory allocation allowed 


Creates a link between two machines 
Subsequent dynamic memory allocation allowed 


Multiple calls provide multiple links to one or 
more other machines 


dynamicmachinepaths 





main(argc,argv) 


[III OOOO OOOO OOO OOOO OOO OO OOOO IO ORO ROROIOIOOIOIOROIOIOIOIOIOROIOIOIOIOIO NO 


SYSTEM INITIALIZATIONS 


ERAN NO RR MR RR RARA [ 


/* Open up the net path to other machine (iris3 default) */ 
dynamicmachinepath(2,other_machine,4,5,"server",&cardriver,2000000); 


Figure 5.5 Server Creation 


requirement for a default specification. Figure 5.6 illustrates one way to accomplish this 
for a client. This example does not require that the network alias be defined to the 
System as it uses the complete address. The user, however, only enters the alias. 

(2) Program Use. The simplest high-level communication paradigm is 
reading from and writing to the other machine. It closely parallels handling files and 


terminals in C. It was chosen for these reasons. 


Twelve high-level functions are available. Four provide status 
information, four write to other machine, and four read from other machine. Table 5.4 
describes these functions. The parameters used by these calls are described in Appendix 


A, Sections l.a and 9.a. 
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main(argc,argv) 


int ear ee /* argument count */ 
char *argvb- /* pointers to the passed in arguments */ 


| 


f "eo eoe oco decolor colo cR ooo po oco po KE 


DATA DECLARATION 


we He He: He e ae ole eoe RR RR N E Ln ae 


char other machine[50]; /* name of other machine */ 


[ RRS EERERRREREREERER EERE e mhe de e afe e AAN WORK XR HO I aoo c ee 


SYSTEM INITIALIZATIONS 


vii) 


/* pull out the string from the argument list */ 
if(arge > 2) 
( 
printf("NAV: incorrect argument count! use nav <alias>in”); 
exit(1); 
| 
/* pul! out the name of the other string, if it exists */ 
if( arge == 2 ) 
| 
strcpy( other machine, "npscs-" ); 
strcat( other machine, argvf1] ); 


| 


else 
strcpy( other machine, "npscs-iris2" ); 


/* Open up the net path to other machine (iris2 default) */ 
dynamicmachinepath(2,other machine,5,4,"client",&car,2000000); 


Figure 5.6 Command Line Direction for Connection 


There is a variety of ways to use these functions. Figure 5.7 
illustrates a typical scenario. This code is from the display station of a two-workstation 
driver simulation. The display station provides its status (that of the world") on each 
pass through its graphical display loop. The control station must read that status on each 
pass, to update the vehicle position on its track diagram. On each pass, the display 
station checks to see if any commands have been received. This is an asynchronous 


communication, as the display station continues with or without a control station 
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command. The asynchronous reads are guarded by a receiver has data call that detects 
arrival of a message. Other receiver_has data calls are used to “busy wait” for the next 
message. In practice, it has not been necessary to include any but the first “busy wait” 
receiver has data call. TCP/IP buffers messages when they are not immediately read. 
It then blocks them into the largest grouping possible and delivers them when the next 
read occurs. The LARGESTREAD defined constant in sAared.h determines this 
maximum grouping. The first message is read by receive. The socket is then ignored 
until the application reads the data. During this time, the other messages have all been 
sent and buffered by TCP/IP. There is a slight delay between the time the first message is 
read and the block containing all the rest is read. Thus the necessity for the first “busy 
wait" receiver has data call. The other "busy wait" receiver has data calls are simply 


for robustness. 


The "busy wait" sender is free call determines if something has 
happened to the other machine or Ethernet. The first write will always succeed, as it goes 


to a buffer. If there is a communications problem, TCP/IP will not accept it and the 


Table 5.4 COMMUNICATION FUNCTIONS 


Function Action 
sender is free Retums TRUE if a message can be sent. 
receiver has data Retums TRUE if a new message has been received. 


received type Retums a character indicating the type of the message. CHARACTER TYPE, 
INTEGER, TYPE, and FLOAT TYPE are predefined. CHARACTER ARRAY TYPE, 
INTEGER, ARRAY TYPE, and FLOAT ARRAY TYPE are predefined. 


number received Retums an integer indicating how many elements in message. 
write character 


write integer 
write float 
write characters 
read character 
read integer 
read float 

read characters 


Send a single value of the type to other machine. 


Move single value of named type from buffer to application program storage. 
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main(argc,argv) 


[BE AIAAAIAAAA AIA IAA ARIA AIA RITA SISI AA III AAA III AA IAA IAAAA 


MAIN SIMULATION LOOP 


MACHAC AE RM ACA AAA AAA ERE DS ER EIA) 


while(vehicle.command.condition != DONE) 


I 


[**** kde Hoe de EERE ECE EEE SOE EEE CECE Te RUF NE E S E ERUKKUR 


Get commands (if any) from navigator. Commands are all sent 
or none are sent so no information is needed as to which value 


is which. 
cde deese e o ooo ooo oo o Fo A 


if( receiver has, data( &cardriver ) ) 

( 
read integer(&cardriver, &vehicle.conmand.condition); 
while( !receiver has, data( &cardriver ) ) /*printf("1")*/; 
read integer(&cardriver, &vehicle.conmand.brakepedal):; 
while( !receiver has data( &cardriver ) ) /*printf("2")*/; 
read integer(&cardriver, &remote mousex); 
while( !receiver has data( &cardriver ) ) /*printf("3")*/; 
read float(&cardriver, &cmdspeed); 


f 5** tese eoe ok do RARA ooo ooo oe de eo e eX Ro Roc e so cO 


Report all status information to navigator every cycle. 
dek Rok dedo koe o Aot Rodeo He e A Ro Roe dodo RR RR Rodeo RR RR ROI ROIG eR RGRGROR ] 


write float(&cardriver, &vehicle.state vector[1]); 

while( !sender is free(&cardriver) ) printf("b"); 

write float(&cardriver, &vehicle.state vector[2]); 

write float(&cardriver, &vehicle.state vector[3]); 

write float(&cardriver, &vehicle.situation.distance. traveled); 
write integer(&cardriver, &vehicle.conmand.condition); 

write integer(&cardriver, &vehicle.command.brakepedal); 

write integer(&cardriver, &vehicle.situation.lightcolor):; 


]) /* while loop */ 


) /* main */ 


Figure 5.7 Synchronous Write / Asynchronous Read 
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sender is free call will return FALSE. This often occurs when there is a delay by the 
client in connecting to the server (the display station here). If there is a good connection, 
TCP/IP will accept and buffer all input. No other “busy wait” calls are needed. The other 
side of the communication is shown in Figure 5.8. | 

(3) Disconnection. Termination, with a deletemachinepath call for 


each path opened, is mandatory. If not performed, the sockets (and shared memory 


seginent on System V UNIX machines) will not be retumed to the system. Problems” 


may then occur on the next run. Figure 5.9 is an example termination when multiple 
paths have been opened [Ref. 11]. 
2. Lisp Machines 

All necessary functions are contained in a single file. This file must be loaded 
before use. Figure 5.10 is an example. A Lisp machine is always a client and is started 
second. Figure 5.11 illustrates the message returned with a successful connection. 
Unsuccessful connections “hang” and return nothing. 

a. Connection 

The address of the server and the ports it is using must be specified. 

Figure 5.12 shows the ports specified as part of the loaded file. When using the older TI 
Explorer functions, the addresses are specified in the same way (see Figure 4.5) and then 
the machine desired is requested by number?” (shown in Figure 5.13). When using the 
stream-based functions, the addresses are not specified by the user at all. The network 
tables are accessed, by host name, through the select-host function provided (shown in 


Figure 5.14). Once the instance of conversation-with-iris flavor has been completed 


26 See Tables 5.1 and 5.2 


27 A throwback to connection only with different IRIS machines. 
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main(argc,argv) 


while(condition != DONE) 


f Atho ooo ooo EA RO c KK RERUM 


Receive all status information from car every cycle. 
At Xs ooh dot o SA) 


while( !receiver has data( &car ) ) ; 
read float(&car, &cy); 

while( !receiver has data( &car ) ) ; 
read float(&car, &cx); 

while( !receiver has data( &car ) ) ; 
read float(&car, &velocity); 

while( !receiver has data( &car ) ) ; 
read float(&car, &rdistance); 

while( !receiver_has_data( &car ) ) ; 
read_integer(&car, &condition); 
while( !receiver has data( &car ) ) ; 
read integer(&car, &brakeposition); 
while( !receiver has data( &car ) ) ; 
read integer(&car, &lightcolor); 


[ A HR ooo oo oe ARMAR AAA NAO A OR ade E aie ade sbe e eA SOS Foie i 


Send commands (if any) to car. Commands are all! sent 
or none are sent so no information is needed as to which value 
is which. 


cole de oo v S Pede e ooo So AEREA R 


if(anything has, changed) 

( 
anything_has_changed = FALSE; 
write_integer(&car, &condition); 
while( !sender is free( &car ) ) printf("a") ; 
write integer(&car, &brakeposition); 
while( lsender-is free( &car ) ) printf("b") ; 
write integer(&car, &mousex); 
while( !sender is free( &car ) ) printf("c") ; 
write float(&car, &cmdvelocity); 

|] /* if(anything has changed) */ 


) /* while */ 


] a */ 


Figure 5.8 Reciprocal Synchronous Read / Asynchronous Write 
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deletemachinepath(&TI); 

deletemachinepath(&SYM3): 
deletemachinepath(&SYMI ) ; 
deletemachinepath(&SYMA) ; 


exu tt): 


Figure 5.9 Connection Termination 


7-33 this is the communication package 
(load "irisflavor") 


Figure 5.10 Loading Lisp Flavor 


"A conversation with the iris machine has been established" 


Figure 5.11 Lisp Connection Message 


Mdefvar *irisl.portl* 1027) ; this is the send port 
(defvar *irisl-port2* 1026) : ; this is the receive port 


Figure 5.12 Setting Port Numbers with defvar 


ri get the network going 

uris) 

(setq *battle* (make-instance 'conversation-with-iris)) 

(if (y-or-n-p "start networking ?") (send *battle* :start-iris)) 


Figure 5.13 Specifying Server in Lisp 


SI 


(select-host iris2) 


Figure 5.14 Specifying Server by Name in Lisp 


with port numbers and host addresses, the connection is established with the method 
:start-iris, see Figure 5.13. 
b. Program Use 
The method :get-iris returns with the object sent by one message. The 
method (:put-iris object) sends the object as one message. Figure 5.15 illustrates both. 
Note how methods are added to flavor conversation-with-iris to simplify the 
application interface even further. [Ref. 11] 
c. Disconnection 
Disconnection is accomplished with the method :stop-iris, shown in 


Figure 5.16. 


C. BROADCAST 

Only UNIX-based machines support our broadcast protocol at this time. It is a 
unidirectional protocol, but nothing prevents the establishment of two unidirectional 
channels in opposite directions. Using two broadcast channels to emulate a direct 
connect channel, however, loads all other machines on the network by requiring every 
other machine to process each message. It is also less reliable. Broadcasting is good for 
sending status information to many other machines, as long as those machines can 
tolerate missing reports. 

l. Similarities With Direct Connect Protocol Use 

Using the broadcast protocol is similar to using the direct connect protocol. 


The same functions are used in the same way. Each connection must set aside space as 
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-:: definitions: 


. è. 
Lm SJ 


nl object: n^ name: character “1” 11.55 

DSS X x coordinate: real 

S y y coordinate: real 

us Z z coordinate: real 

ae spd speed: real speed of vehicle -10.00 to 25.00 
$us dir direction: real compass dir in degrees from GN 
ates in lisp ("n” (x y z spd dir)) 


333 get an object in graphics environment (defined as above) 


(defmethod (conversation-with-iris :object) 
() 
(makeob y 
(send self :get- iris) 
(send self “pet-iris) 
(send self :get-iris) 
(send self :get-iris) 
(send self :get-iris) 
(send self :get-iris) ) ) 


733 vision returns a list of objects in the tank's field of vision (100m radius) 
eeens is effectively an association list 


(defmethod (conversation-with-iris :vision) 
(tank) 
(let ((field nil) 
(n-objects 0) ) 
(progn (send self :put-iris "V") 
(send self :put-iris tank) 
(if (equal "V" (send self :get-iris)) 
(progn (setq n-objects (send self :get-iris)) 
(do times 
(x n-objects field) 
(setq field (cons (send self :object) field)) ) )' 
(progn 
(print "iris did not respond to the vision command sent from ") 
(princ "tank ") 
(princ tank) ) ) ) ) ) 


Figure 5.15 Application Communication in Lisp 


in Figure 5.4. The same criteria for using a specific machinepath call apply (see Table 
5.3). The same communications functions are available as in Table 5.4. Each 


connection must be terminated as in Figure 5.9. 
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(if (y-or-n-p "stop iris connection ?") (send *battle* :stop-iris)) 


Figure 5.16 Termination of Communications in Lisp 


2. Differences With Direct Connect Protocol Use 
a. Application Setup 

The broadcast protocol is not directly modeled as a server/client 
relationship. The broadcaster broadcasts to whomever is prepared to receive. The 
receiver must be ready and so must be started first. Since the broadcaster is more similar 
to the server in a server/client model, this connection order seems exactly backward. No 
error will result if the broadcaster starts first, messages will simply not be received. The 
receiver message is shown in Figure 5.17. The broadcaster message is shown in Figure 
5.18. When a direct connect channel is also required between the same two machines, 
achieving proper startup order is easy. Establish the direct connect channel first, then the 
soon-to-be broadcasting process sends a message telling the receiver to start up. Once 


started, the receiver process sends a message permitting the broadcaster to start. 


ready to receive from broadcaster name 


Figure 5.17 Normal Receiver Response 


Walting to broadcast 


Figure 5.18 Normal Broadcaster Response 
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b. Coding Practices 
The parameters to the machinepath family of functions are used 
differently for the broadcast protocol. All are required to be present, but some are 
ignored (see Table 5.5). Since a broadcast channel is unidirectional, the receive type 
application calls are meaningless to the broadcaster (the receiver has data call always 
retums false). The send type application calls are meaningless to the receiver (the 


sender is free call always returns false). 


D. SUMMARY 

Using the same functions, an application can either broadcast or directly connect to 
another machine. The same steps of setup, connection, use, and termination are common 
to both protocols. Care must be taken in the timing of the two (or more) machines setup. 


After that, an application merely reads or writes data. 
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Table 5.5 MACHINEPATH PARAMETERS 
Function 


— 


Arbitrary integer. Should be different than another 
segmentnum user's application. 






Number of channels that could 
be created by application. This 
includes both DIRECT CON- 
NECT and BROADCAST chan- 
nels. 










Only first call's value used. 


DIRECT CONNECT and BROADCAST (receiver 
e only): Name of machine to connect to. 

BROADCAST (broadcaster only): Required but ig- 

nored 


DIRECT CONNECT: Number (0-3076) of port to be 
used to send to other machine. 

sendportnum BROADCAST (broadcaster only): Number (0-3076) 
of port to be used for broadcast. | 
DIRECT CONNECT: Number (0-3076) of port to be 
used to receive from other machine. 


receiveportnum | M (broadcaster only): Required but ig- 


BROADCAST (receiver only): Number (0-3076) of 
port to be used for broadcast. 






"server": Create DIRECT CONNECT channel 
hal as a server. — — 5 
"client": Create DIRECT CONNECT channel 
as a client. 
server ( | 
"broadcast": | Create BROADCAST channel as a 
| broadcaster. 
"receive": Create BROADCAST channel as a 
receiver. 


instructure Address of Machine structure created to hold channel 
information. 


Amount of space to be used for 
freespace dynamic memory allocation. 
| | Only first call's value used. 
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VI. PERFORMANCE 


A. INTRODUCTION 

We look at the size of packets from our protocols. We also look at the effect of real 
applications on the network. We try to do this for both direct connect and broadcast 
protocols. However, no application making good use of broadcast protocols exists. 
Hence, we used a direct connect test application and replaced the channel with two 


broadcast channels. 


B. DATA COLLECTION 


The LANalyzer' EX 5500 network analyzer was used to gather Ethernet statistics. 


Version 2.0 of the software was used. The LANalyzer 5500 is a COMPAQ PORTABLE 


II" with a coprocessor board installed. The coprocessor board has an Intel 80286 CPU, 
an Intel 82586 LAN coprocessor, and two MBytes of memory. It performs packet 
collection, packet filtering, and network statistics calculation. The COMPAQ PORTABLE 


II processor handles user software control, screen updating and disk I/O. [Ref. 29] 


Samples were taken while direct connect applications were running on iris2 and 


iris. To compare direct connect protocol with the broadcast protocol, test programs 


were used”. Table 6.1 summarizes the information collected. These programs send a 
character string, an integer, and a floating point number in a rotating sequence. The 
messages are either sent to the machine specified on the command line or are broadcast 


to all machines on the local network but only received from the machine specified. 


" LANalyzer is a registered trademark of Excelan, Inc. 
"* COMPAQ PORTABLE II is a tradmark of the COMPAQ Computer Corporation. 


28 See programs prog.c, prog2.c, gprog.c, and gprog2.c in Appendix D. 
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Table 6.1 DIRECT CONNECT VERSUS BROADCAST STATISTICS 


Direct Connect Broadcast 
Run Number Ave Max Number Ave Max 
of Packet Test of Packet Test 
Number Packets Size Load Pa Size n 
bytes To bytes 


[ 96 | «05. 
— EX 
is 0 

The visual simulation application measured was a modified version of the driving 
simulator [Ref. 7]. Table 6.2 summarizes the information collected. This data was 
taken during the day?”. The applications communication code is shown in Figure 5.7 
and Figure 5.8. One trip around the track took approximately five minutes. Seven 
messages are sent every cycle to report status. Four messages are sent in the opposite 
direction, as required, to control the car. One circuit was driven, on autopilot, for each 
test run. There were about 500 cycles per test. Approximately 3600 messages were 
generated per test. The number of packets sent was less than half of this. The apparent 
discrepancy exists for two reasons. First, each packet sent also generates an 


Table 6.2 APPLICATION NETWORK USE STATISTICS 































Number | Average Peak | Average 
of Packet Network 
Size Load 
Packets en %) 


A ore a i 


mnm wit mm O O is 
2 163297, | OA A 
— INNATA A (| ew] ow 
ast Nr EN ES 
| ST | 22830 | AAA 


2 At night, with less competition for network resources, the results were similar. 
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acknowledgement packet in return. By acknowledging each packet, the stream socket 
guarantee of delivery and proper sequence is met. Second, after the first packet 
(containing the first message) is received, the remaining three or six messages are 
unmediately sent. The receiving process has often not yet handled the E one. The 
remaining messages are combined into one and all are read as one block. This reduces 
the interchange to a typical total of four packets per cycle, two with data and two for 
acknowledgement. Similarly, four packets are usually generated whenever the navigator 


process issues a command sequence to the car. 


An evaluation of a five-workstation application [Ref. 11] was also made. This 
application used three Symbolics (sym, sym3, and sym4), expl, and iris2 to perform its 
tasks. Statistics were similar to the other application, but the Symbolics irisflavor.lisp ? 
exhibited some problem behavior. It sent three packets for every message. The first 
packet contained the type field only. The second packet contained both the type field 
and the length field. The third contained the entire message. If a second message 
immediately followed the first, three more packets were sent, each adding one field to the 
previous packet. Only one acknowledgement was received, as all packets in a group had 


the same identification number. 


C. DISCUSSION 

Attempting to use broadcast protocol with the simple test programs failed. One 
problem encountered was overflow of the sending buffer within the TCP/IP layers. The 
rapidity of attempted transmission was the cause. Higher network loading exacerbated 
the problem. When the test application was slowed down with printf calls (and the 


output redirected into a file) the buffer could keep up with sending requests. Using 


30 See Appendix C 
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broadcast protocol within a graphics display loop should pose no problems unless 


numerous data elements are transmitted at one time. 


Without acknowledgement packets, broadcasting put fewer packets on the network 
than did the direct connect protocol. When overall load was haevy, some were lost. This 
poses a serious problem for visual simulation applications. Without an elaborate 
application-level protocol, the receiving process will never know what was intended to 
be sent. Since only one data object is transmitted at a time, labeling the data objects is 
difficult. All that is available is to altemately send different types and, after checking 
the type received, make a determination of the likely intent of the sending process. If a 
block of data, containing different types, could be sent as a single message, the decoding 
problem would become one of simply sequence checking. Missing status packets can be 
safely ignored in many situations. At most, a simple averaging algorithm can smooth 
any discontinuities caused by a missing packet. Timestamping, with a virtual timestamp, 


of each packet would eliminate the averaging requirement. 


The Symbolics stream version is much less efficient, in terms of network 
utilization, than is the Explorer's. It still functions correctly, with no noticeable delay. 
As the amount of data to transmit increases, the Symbolics flavor will eventually have 


noticeable performance degradation. 


The interconection of five machines loads the network only slightly more than does 


that of two. The limitation will be from the process swap overhead, not the network. 


D. SUMMARY 

The direct connect protocol sends fewer packets than messages. Half of the packets 
sent are acknowledgements. These acknowledgements provide the reliability of the 
direct connect protocol. The broadcast protocol sends one packet for each message. 


These packets tend to be smaller than those for the direct connect protocol. Until a 
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mechanism exists to bundle several messages into one broadcast packet, the broadcast 


protocol is of small value. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. LIMITATIONS 

There are two primary limitations. First, the Lisp and C functions differ at the user 
level. This was done to allow each to be used readily by programmers "thinking" in their 
respective language. We have found this to be confusing to students who are 
inexperienced in both languages. Second, there is no simple means to transmit a block of 
data or an entire file. Each data element, unless it is part of an array of characters, must 
be sent separately. This was done to “hit a middle ground” between a complex 
facility—printf function—and low-level system calls. As long as only the direct connect 
protocol existed, this was only an annoyance. As discussed in Chapter 6, this is a 


critically limiting factor for the broadcast protocol. 


The port to BSD UNIX systems without shared memory and semaphores was not 
completed. The socket handling aspects are portable, but the shared memory aspects are 
interwoven throughout the system. The difficult part of the porting will be designing the 
message-passing protocol for the pipe between the application and the send and receive 


processes, as discussed in Chapter 4. Other specific limitations include: 


e no broadcast capability for Lisp machines 
e no server capability for Lisp machines 


e limited communication error handling-—no signals are sent from the send or receive 
processes to the application process if they encounter problems 


e limited read/write error handling—a read or write of the wrong type will be 
attempted and usually produce garbage 


e no out-of-band capability 
e Symbolics iris-flavor.lisp creates three packets per message 
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B. FUTURE RESEARCH AREAS 

Implementation of the missing structure data type is one key area in which more 
work could be done. The most straight-forward solution to this would be to add 
messages to the send section of the shared memory array without signalling the send 
process to send it until the entire block was ready. Such a solution eliminates any need to 
change the receiving functions at the cost of either an additional sending function or an 
additional parameter to the existing send functions. The additional send function would 
be a push function and the existing send functions would be modified to never signal the 
send process to send. That would be left to the new push function. Adding a parameter 
to each send function would allow any send function to push. While in some respects 
simpler, changes to any application sending a block of data would have to carefully 


monitor which send function actually is pushing. 


Creation of a Lisp flavor that mimics the UNIX functions would prove useful to C 
programmers who find a need for Lisp modules in their visual simulation. Adding server 
and broadcast capabilities would increase the applicability of the protocols to future 
visual simulation projects. Functions to break complex Lisp objects into simple ones and 
then combine these into a single message are necessary for the broadcast protocol. The 


Symbolics version should be corrected to send a packet only at message boundaries. 


C. SUMMARY AND CONCLUSION 

The routines described herein have already proved useful to researchers at the Naval 
Postgraduate School. With Ethernet loading never exceeding one percent, these routines 
are efficient enough to use without concern. With the additions mentioned above, the 


goal of an easy-to-use yet powerful system will be reached. 
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APPENDIX A - IRIS MODULE DESCRIPTIONS 


l. io single.c 
a. Calling Protocols 
This module contains functions that are intended for the application’s use and 
functions that are used exclusively by them. The parameters for externally accessible 
functions are described below. 


i. number received 


number received( instructure ) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
ui 


ii. read character 
read_character(instructure,character_out) 
Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment */ 
char *character_out; /* pointer to output character */ 


ili. read characters 
read_characters(instructure,outarray,arraysize) 


Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment */ 
char outarray[]; /* output character buffer */ 
int arraysize; /* the number of characters to be returned */ 


iv. read float 


read_float(instructure,float_out) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment */ 
float *float_out; /* pointer to output float */ 


v. read integer 


read_integer(instructure,integer_out) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment */ 
int *integer_out; /* pointer to output integer */ 
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io single.c 


vi. received type 


char received type( instructure ) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
si 


vi. write character 
write character(instructure,character in) 


Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
char *character in; /* pointer to input character */ 


viii. write characters 
write characters(instructure,inarray,arraysize) 


Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment 
int instructure.receivesem the semaphore to the receiver. 
char *inarray; /* input character buffer */ 
long arraysize; /* the number of characters input */ 


ix. write float 


write float(instructure,float in) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
float *float in; /* pointer to input float */ 


x. write integer 


write_integer(instructure,integer_in) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
int *integer_in; /* pointer to input integer */ 
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«i 


io_single.c 


b. Code and Description 


HA k k ak kok k de k k e oe e ade ade e ade de ad ae ade ae ade ale ode de ade de e ed le ae e ade ad al k de e ad ae e a ae e ade a ae e e ae ae ad ae ae ade ale ale de ae ad ade e de xe ok oe oo ok ox 
/ 

* * 
* TITLE : Inter-Computer Conmunication Package * 
* * 
* MODULE : io_single.c > 
* * 
* VERSION: 3.0 * 
* * 
* DATE : 15 December 1987 T 
* * 
* AUTHOR : Theodore H. Barrow 4 
* * 
Kk o ok oi e o RR Ro KR XR ORO XO OK SR OIOROI A OIOIOR III IA RARI AAA RA AAA IAA A AAA AIA AA k k k IRR AAA ARA OH 
* + 
* HISTORY: * 
* + 
> VERSION: 1.0 * 
* * 
x DATE : 27 May 1987 * 
* * 
È AUTHOR : Theodore H. Barrow y 
x * 
5 DESC.  : Originally part of support.c. Contains the documented read i 
* and write calls for use by the application programmer. i 
* * 
* VERSION: 2.0 * 
* * 
* DATE : 21 October 1987 * 
x * 
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#include “shared.h" 
#include "gl.h" 


/* The following routine copies a character into the shared segment. 
It puts the type CHARACTER TYPE in the first byte and the 
length 0001 into the next four bytes. 
It then puts the total size at the top of the shared segment. 
It then sends a wakeup to the sender program. 
It uses an input structure since called by main program 


2 
write character(instructure,character in) 


Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
char *character in; /* pointer to input character */ 


( 
int msgsize = 5 + CHARACTER_SIZE; /* size of message */ 


char *senderstart = instructure->segment + SENDEROFFSET; 
/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 


char *datastart = senderstart + 9: 


long *sentlength = (long *)instructure->segment + WSENDEROFFSET; 


, inšert the type code */ 
*(senderstart + 4) = CHARACTER_TYPE; 


/* insert the length IN BYTES of the input data */ 
sprintf((senderstart + 5), "704d", CHARACTER SIZE); 


/* move -the data bytes */ 
memcpy(datastart, character in, CHARACTER SIZE); 


/* copy out the size of the data from the shared segment top */ 
*sentlength = msgsize; 


/* at this point, we send a wakeup to the sender program, 
indicating that he can reuse the shared segment. 
n 


V(instructure->sendsem); 


} /* write_character */ 
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/* The following routine converts an integer to a string and copies it 
into the shared segment. 

It puts the type INTEGER_TYPE in the first byte and the string length 
(in bytes) as an integer (in string format) into the next four bytes. 
then puts the total size at the top of the shared segment. 
then sends a wakeup to the sender program. 

It uses an input structure since called by main program 

"a 
write_integer(instructure,integer_in) 
Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
int *integer_in; /* pointer to input integer */ 
| | | | | 

char integer string[20]; /* string for integer conversion */ 

int length; /* length of integer string */ 

int msgsize; [* size of message */ 


char *senderstart = instructure->segment + SENDEROFFSET; 


/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = senderstart + 9; 


long *sentlength = (long *)instructure->segment + WSENDEROFFSET; 


/* convert integer to string m 
sprintf( integer string," ?od", *integer in ); 


/* find length of integer string and thus message */ 
length = strlen( integer_string ); 
msgsize = 5 + length; 


/* insert the typescodes™, 
*(senderstart + 4) = INTEGER_TYPE; 


/* insert the length IN BYTES of the input data */ 
sprintf((senderstart + 5), "%04d", length); 


/* move the data bytes */ 
memcpy(datastart, integer_string, length); 


/* copy out the size of the data from the shared segment top */ 

*sentlength = msgsize; 

/* at this point, we send a wakeup to the sender program, 
indicating that he can reuse the shared segment. 

M 


V(instructure->sendsem); 


[* write-integer %/ 
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/* The following routine converts a float to a string and copies it 
into the shared segment. 
It puts the type FLOAT TYPE in the first byte and the length 
(in bytes) as an integer (in string format) into the next four bytes. 
It then puts the total size at the top of the shared segment. 
then sends a wakeup to the sender program. 
It uses an input structure since called by main program 


Bí 
write float(instructure,float in) 


Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment 
int instructure.sendsem the semaphore to the sender */ 
float *float_in; /* pointer to input float */ 


| 


char float string[30]; /* string for float conversion */ 
int length; /* length of float string */ 
int msgsize: ¡ze Of message *7 
char *senderstart = instructure->segment + SENDEROFFSET ; 
/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = senderstart + 9; 


long *sentlength = (long *)instructure->segment + WSENDEROFFSET; 


/* convert float to string */ 
sprintf( float_string, "%f", *float_in ); 


/* find length of float string and thus message */ 
length = strlen( float_string ); 
msgsize = 5 + length; 


f insert the type code */ 
*(senderstart + 4) = FLOAT_TYPE; 


/* insert the length IN BYTES of the input data */ 
sprintf((senderstart + 5), "%04d", length); 


/* move the data bytes */ 
memcpy(datastart, float_string, length); 


/* copy out the size of the data from the shared segment top */ 
*sentlength = msgsize; 


/* at this point, we send a wakeup to the sender program, 
indicating that he can reuse the shared segment. 
= 


V(instructure->sendsem); 


) /* write_float */ 
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io_single.c 
/* This routine returns the type of data received 


char received_type( instructure ) 


Machine *instructure; /* includes 
char *instructure. segment a pointer to the shared segment 
ud 


return( *(instructure->segment + RECEIVEROFFSET + 4) ); 
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/* This routine returns the number of data items received. */ 


number_received( instructure ) 


Machine *instructure; /* includes 


) 


char *instructure. segment a pointer to the shared segment */ 


int temp_int; 


char *protocolhold instructure->segment + PROTOCOLHOLDOFFSET:; 


long *partreceived (long *)protocolhold; 


long *receivedlength = (long *)instructure->segment + WRECEIVEROFFSET; 
char *receiverstart = instructure->segment + RECEIVEROFFSET; 
/* check if only part of protocol information received */ 


if( *receivedlength « 5) 

( 
/* move data received (as well as length field) to holding area */ 
memcpy( protocolhold, receiverstart, *receivedlength + 4 ); 


/* get next message(s) */ 
free_receiver(instructure->segment); 
V(instructure->receivesem); 

enile. receiver iS free(instructupe-ssesment) ) walt */ ; 


/* copy rest of protocol data into holding area */ 
memcpy( (protocolhold + *partreceived + 4), (receiverstart + 4), 
(5 - *partreceived) ); 


else 

| 
/* copy protocol data into holding area */ 
memcpy( protocolhold, receiverstart, 9); 


D* inittalize *partreceived so it cen be used later */ 
*partreceived = 0; 


| 


/* determine the length of the received integer string and thus message */ 
sscanf( protocolhold + 5, "%d", &temp_int ); 


switch( *(protocolhold + 4) ) 
| 
case CHARACTER TYPE: 
return( 1l ); 
break: 
case INTEGER TYPE: 
return( 1 ); 
break; 
case FLOAT_ TYPE: 
Feturn( 1 >): 
break; 
case CHARACTER ARRAY TYPE: 
return( temp int/CHARACTER SIZE ); 
break: 
case INTEGER ARRAY TYPE: 
return( temp int/INTEGER SIZE ); 
break; 
case FLOAT ARRAY TYPE: 
return( temp int/FLOAT SIZE ): 
) 


/* number_received */ 
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/* The following routine returns a character from the shared segment. 


It frees the receiver side of the shared segment if it is empty. 
lt then sends a wakeup to the receiver program. 
It uses an input structure since called by main program. 


E 
read_character(instructure,character_out) 
Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment */ 
char *character_out; /* pointer to output character */ 


| 


/* temporary storage for move of received data or for protocol information 
when partial receipt */ 

char temp[LARGESTREAD]; 

char *protocolhold = instructure->segment + PROTOCOLHOLDOFFSET ; 


/* first four bytes of holding area as integer */ 
long *partreceived = (long *)protocolhold; 


5 + CHARACTER _ SIZE; /* size of message */ 


int msgsize 
char *receiverstart = instructure->segment + RECEIVEROFFSET; 


/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = receiverstart + 9; 


long *receivedlength = (long *)instructure->segment + WRECEIVEROFFSET; 


/* check if first part of protocol information is missing */ 
if( *partreceived == 


/* check if only part of protocol information received */ 

if( *receivedlength <= 5) 

| 
/* move data received (as well as length field) to holding area */ 
meme py( protocolhold, receiverstart, *receivedlength + 4 ); 


/* get next message(s) */ 
free_receiver(instructure->segment); 
V(instructure-»receivesem); 

while( receiver is free(instructure-»segment) ) /* wait */ ; 


/* reset msgsize and datastart to correspond to partial receipt */ 
msgsize -= *partreceived; 


datastart -= *partreceived; 


/* move the bytes */ i 
memcpy(character out, datastart, CHARACTER SIZE); 


/* make buffer ready for next read */ 
reset buffer( receivedlength, msgsize, instructure, datastart, 


CHARACTER, SIZE, partreceived, receiverstart ); 


/* read character */ 
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/* The following routine converts a string in the shared segment 
into the returned integer. 
frees the receiver side of the shared segment if it is empty. 
It then sends a wakeup to the receiver program. 
It uses an input structure since called by main program. 


ny 
read integer(instructure,integer out) > 
Machine *instructure; /* includes 

char *instructure. segment a pointer to the shared segment */ 
int *integer_out; /* pointer to output integer */ 


{ 
char integer string[LARGESTREAD]; /* string storage for received data */ 


char *protocolhold = instructure->segment + PROTOCOLHOLDOFFSET ; 

/* first four bytes of holding area as integer */ 

long *partreceived = (long *)protocolhold; 

int length; /* length of integer string read */ 
long segmentlength; /* length of data of partial massage */ 
int msgsize; /* size of message */ 


char *receiverstart = instructure->segment + RECEIVEROFFSET; 


/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = receiverstart + 9; 


long *receivedlength = (long *)instructure->segment + WRECEIVEROFFSET; 


/* determine proper protocol info and reset variables if necessary */ 
get_protocol( protocolhold, partreceived, réceivedlength, réceiverstart, 
instructure, &length, dmsgsize, &datastart ); 


/* check if only part of data has been received */ 


if( *receivedlength « msgsize ) 


| 


get data( &segmentlength, receivedlength, partreceived, 
integer string, &datastart, &msgsize, 
receiverstart, instructure, &length); 


/* convert to string */ 
integer_string[segmentlength + msgsize] - 'NO'; 


else 


/* move the integer string bytes */ 
memcpy(integer string, datastart, length); 


/* convert to string */ 
integer string[length] = '*NO'; 
| 


/* convert the received string to an integer */ 
sscanf( integer_string, "%d", integer_out ): 


/* make buffer ready for next read */ 
reset buffer( receivedlength, msgsize, instructure, datastart, length, 
partreceived, receiverstart DE 


] f" read integer */ 
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/* The following routine converts a string in the shared segment 
into the user supplied float. 
It frees the receiver side of the shared segment if empty. 
then sends a wakeup to the receiver program. 
It uses an input structure since called by main program. 


ny 


read float(instructure,float out) 


Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment */ 
float *float out; /* pointer to output float */ 


| 
char float string[LARGESTREAD]; /* string storage for received data */ 


char *protocolhold = instructure->segment + PROTOCOLHOLDOFFSET ; 


/* first four bytes of holding area as integer */ 
long *partreceived = (long *)protocolhold; 


int length; /* length of float string read */ 
long segmentlength; /* length of data of partial massage */ 
int msgsize; /* size of message */ 


char *receiverstart = instructure->segment + RECEIVEROFESET; 


/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = receiverstart + 9; 


long *receivedlength = (long *)instructure->segment + WRECEIVEROFESET; 


/* determine proper protocol info and reset variables if necessary */ 
get_protocol( protocolhold, partreceived, receivedlength, receiverstart, 
instructure, &length, dmsgsize, &datastart ); 


/* check if only part of data has been received */ 
if( *receivedlength < msgsize ) 
| 
get data( &segmentlength, receivedlength, partreceived, 
float string, &datastart, &msgsize, 
receiverstart, instructure, &length); 


[* convert to string */ 
float string[segmentlength + msgsize] = ’\Q’; 


| 


else 


| 


/* move the float string bytes */ 
memcpy(float string, datastart, length); 


/* convert to string */ 
na ESO mc NOS 


| 


/* convert the received string to an float */ 
sscanf( float string, "97", float out ); 


/* make buffer ready for next read */ 
reset buffer( receivedlength, msgsize, instructure, datastart, length, 
partreceived, recetverstart |): 


} /* read_float */ 
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/* The following routine copies characters from an array 
into the shared segment. 

It puts the type CHARACTER_ARRAY_TYPE in the first byte and the 
array length (in bytes) as an integer into the next four bytes. 
then puts the total size at the top of the shared segment. 
then sends a wakeup to the sender program. 

It uses an input structure since called by main program 


ti 


write_characters(instructure,inarray,arraysize) 


Machine *instructure; /* includes 

char *instructure.segment a pointer to the shared segment 

int instructure.receivesem the semaphore to the receiver. */ 
char *inarray; /* input character buffer */ 
long arraysize; /* the number of characters input */ 


{ 
int datasize = arraysize * CHARACTER_ SIZE; /* size of data field */ 


int msgsize = 5 + datasize; /* size of message */ 
char *senderstart = instructure->segment + SENDEROFFSET; 
/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = senderstart + 9; 


long *sentlength = (long *)instructure->segment + WSENDEROFFSET, 


/* insert the type code */ 
*(senderstart + 4) = CHARACTER_ARRAY_TYPE; 


/* insert the length IN BYTES of the input data */ 
sprintf((senderstart + 5), "%04d", (int)datasize); 


/* move the data bytes */ 
memcpy((datastart), inarray, datasize); 


/* copy out the size of the data from the shared segment top */ 
*sentlength = 5 + datasize; 


/* at this point, we send a wakeup to the sender program, 
indicating that he can reuse the shared segment. 
RT 


V(instructure->sendsem); 


} /* write characters */ 
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/* The following routine copies bytes from the shared segment 


di 


into the user supplied array. 
It frees the receiver side of the shared segment if it is empty. 
It then sends a wakeup to the receiver program. 
It uses an input structure since called by main program. 


read_characters(instructure,outarray,arraysize) 


Machine *instructure; /* includes 
char *instructure. segment a pointer to the shared segment */ 
char outarray[]; /* output character buffer */ 
int arraysize; /* the number of characters to be returned */ 
| 
char *protocolhold = instructure->segment + PROTOCOLHOLDOFFSET ; 
/* first four bytes of holding area as integer */ 
long *partreceived = (long *)protocolhold; 
int length; /* length of character string read */ 
long segmentlength; /* length of data of partial massage */ 


int datasize = arraysize * CHARACTER_SIZE; /* size of requested data field */ 
int requestsize; /* size of message */ 

int msgsize = 5 + datasize; /* size of requested message */ 
char *receiverstart = instructure->segment + RECEIVEROFFSET; 


/* the + 9 is to skip over the first 4 bytes for the size 
of the shared memory data and the 5 bytes of header information */ 
char *datastart = receiverstart + 9; 


long *receivediength = (long *)instructure->segment + WRECEIVEROFFSET; 


/* determine proper protocol info and reset variables if necessary */ 
get protocol( protocolhold, partreceived, receivedlength, receiverstart, 
instructure, &length, &msgsize, &datastart ); 


/* check if all of data (or more) was requested */ 


if( length <= arraysize ) 
| 
/* check if only part of data has been received */ 
1f( *receivedlength < msgsize ) 
| 
get data( &segmentlength, receivedlength, partreceived, 
outarray, &datastart, &msgsize, 
receiverstart, instructure, &datasize ); 


lse 


en (Y — 


/* move the character bytes */ 
memcpy(outarray, datastart, length); 


/* make buffer ready for next read */ 
reset _buffer( receivedlength, msgsize, instructure, datastart, datasize. 
partreceived, receiverstart ); 
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io_single.c 
Ilse 


1 moye ihe bytes */ 
memcpy(outarray, datastart, datasize); 


/* make buffer ready for next read */ 
reset_buffer( receivedlength, msgsize, 


instructure, 


partreceived, receiverstart ); 


/* read_characters */ 


17 


datastart, 


£s, 


datasize, 


io_single.c 


/* These are various support routines used by several of the preceding 
functions. 


2 


reset buffer(receivedlength, msgsize, instructure, datastart, datasize, 
partreceived, receiverstart) 


long *receivedlength; /* first four bytes of receive part of shared seg */ 
int msgsize; /* size of message read */ 
Machine *instructure; /* includes 

char *instructure. segment a pointer to the shared segment 

int instructure.receivesem the semaphore to the receiver. */ 
char *datastart; /* address data starts in receive part of shared seg */ 
int datasize; /* length of data part of message */ 
long *partreceived; /* length of message received in previous block */ 
char *receiverstart; /* address receive part of shared seg starts */ 


| 
char temp[LARGESTREAD]; /* temporary storage for move of received data */ 


/* free the receiver segment if this is only message received */ 
if(*receivedlength == msgsize) 
| 


free receiver(instructure-»segment); 


/* at this point, we shouid send a wakeup to the receiver program, 
indicating that he can reuse the shared segment. 
ai 


V(instructure->receivesem); 


else /* shift data forward in shared memory segment */ 

( 
*receivedlength -= msgsize; 
memcpy(temp, (datastart + datasize), (LARGESTREAD - msgsize)); 
memcpy((receiverstart + 4), temp, (LARGESTREAD - msgsize)); 

/* reset *partreceived for next read */ 


*partreceived = 0; 


} /* reset buffer */ 
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emp ro caco protocolhold, partreceived, receivedlength, receiverstart, 
instructure, length, msgsize, datastart ) 


char *protocolhold; /* protocol holding area */ 
long *partreceived; /* length of message received in previous block */ 
long *receivedlength; /* first four bytes of receive part of shared seg */ 
char *receiverstart: /* address receive part of shared seg starts */ 
Machine *instructure; /* includes 
char *instructure.segment a pointer to the shared segment 
int instructure.receivesem the semaphore to the receiver. */ 
int *length; /* length of data field in message */ 
int *msgsize; /* length of message */ 
char **datastart; /* address data starts in receive part of shared seg */ 


/* check if first part of protocol information is missing */ 
if( *partreceived == 0 ) 


/* check if only part of protocol information received */ 
if( *receivedlength <= 5) 


/* move data received (as well as length field) to holding area */ 
memcpy( protocolhold, receiverstart, *receivedlength + 4 ); 


/* get next message(s) */ 
free_receiver(instructure->segment); 
V(instructure->receivesem); 

while( receiver_is_free(instructure->segment) ) /* wait */ ; 


/* copy rest of protocol data into holding area */ 
memcpy( (protocolhold + *partreceived + 4), (receiverstart + 4), 
(Diet paritrece lived) .): 


| 


else 


| 


/* copy protocol data into holding area */ 
memcpy( protocolhold, receiverstart, 9); 


/* initialize *partreceived so it can be used later */ 
P 
*partreceived = 0; 


/* determine the length of the received data string and thus message */ 
sscanf( protocolhold + 5, "%d", length ); 
*msgsize = 5 + *length - *partreceived: 


/* reset datastart to compensate for possible partial receipt */ 
*datastart -= *partreceived; 


} ("pet protocol */ 
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get data( segmentlength, receivedlength, partreceived, string array, 
datastart, msgsize, receiverstart, instructure, datasize ) 

long *segmentlength; /* length of partial data */ 

long *receivedlength; /* first four bytes of receive part of shared seg */ 

long *partreceived; /* length of message received in previous block */ 

char string_array[]; /* storage for incoming characters */ 

char **datastart; /* address data starts in receive part of shared seg */ 

int *msgsize; /* length of message */ 

char receiveri tami: /* address receive part of shared seg starts */ 


Machine *instructure; /* includes 


int 


| 


char *instructure.segment a pointer to the shared segment 
int instructure.receivesem the semaphore to the receiver. */ 
*datasize; /* length of data field in message */ 


/* determine length of data that has been received */ 
*segmentlength = *receivedlength - 5 + *partreceived; 


/* copy the first segment of data to holding array */ 
memcpy( string array, *datastart, *segmentiength ); 


/* reset msgsize and datastart to correspond to partial receipt */ 
*msgsize -= *segmentlengtl + 5 - *partreceived; 
*datastart = receiverstart + 4; 


/* get next message(s) */ 
free_receiver(instructure->segment); 
V(instructure->receivesem); 
while(-receiver_is_free(instructure->segment) ) /* wait */ ; 


/* cycle through as many messages as it takes */ 
while( *receivedlength < *msgsize ) 


/* copy the next segment of data to holding array */ 
memcpy( &string array[*segmentlength], *datastart, *receivedlength ); 


/* reset msgsize and segmentlength to correspond to partial receipt */ 
*msgsize -= *receivedlength; 
*segmentlength -= *receivedlength; 


/* get next message(s) */ 
free_receiver(instructure->segment); 
V(instructure->receivesem); 

while( receiver is free(instructure-»5segment) ) /* wait */ ; 


} 


/* copy the last segment of data to holding array */ 
meme py( &string array[*segmentlength], *datastart, *msgsize ); 


/* reset datasize to properly reflect last segment size */ 
*datasize = *msgsize; 


|t c pget-datas*/ 
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2. mpath.c 


a. Calling Protocols 


All functions in this module are meant to be accessible by the application. 


5 


These functions set up and tear down the communications path between two machines. 


1.  deletemachinepath 


deletemachinepath(instructure) 


Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 


We base it on the receive portnumber. 
n) 
il. machinepath 


machinepath(segmentnum,mname, sendportnum, receiveportnum,server,instructure) 


long segmentnum; /* the key to use for the created shared segment */ 


char mname[]; /* machinename character string */ 
long sendportnum, receiveportnum; /* send and receive port numbers */ 
char server[]; /* this character String is either "client" or "server". 


It indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 
must be the server. 


e 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 


A; 
lil. dynamicmachinepath 


dynamicmachinepath(segmentnum,mname , sendportnum, receiveportnum,server, 
instructure,freespace) 


long segmentnum; /* the key to use for the created shared segment */ 


char mname [ ]; /* machinename character string */ 
long sendportnum, receiveportnum; /* send and receive port numbers */ 
char server[]; JomUumPsSehapacter stping ıs erther "client" or “server”. 


It indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 
must be the server. 


E 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segmeut -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 
We base it on the receive portnumber. 
ay 
int freespace: /* amount of freespace desired for dynamic memory allocation 


after this routine has been called. */ 
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iv. dynamicmachinepaths 


dynamicmachinepaths(nummachines,segmentnum,mname,sendportnum,receiveportnum, 
server,instructure,freespace) 


int nummachines; /* the maximum number of other machines to be attached */ 
long segmentnum; /* the key to use for the created shared segment */ 

char mname[]; /* machinename character string */ 

long sendportnum,receiveportnum; /* send and receive port numbers */ 

char server[]; /* this®character string is either client” or “sewer E 


It indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 
must be the server. 


a 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 
We base it on the receive portnumber. 
2 
int freespace. /* amount of freespace desired for dynamic memory allocation 


after this routine has been called. */ 


b. Code and Description 


ee eH eRe ade e e fe Me ee fe HC fe fe te he e e ae ae ade ae o e e ae ae ade e ae e ae ae ode e ae o ade ad o ade ae od e e e ae a of e o ae ae od ade e HC fe he k k k k k fe he a te ee of 


TITLE : Inter-Computer Communication Package 
MODULE : mpath.c 
VERSION: 5.0 
DATE : 31 May 1988 
AUTHOR : Theodore H. Barrow 
XA AA AA AAA ARCH IOI III III IOI OI III ICICI III IOI IAA AAA AAA AA IO AAA AAA IAA AA IAA AAA AAA I 
HISTORY: 
VERSION: 1.0 
DATE : 6 February 1987 
AUTHOR : Michael J. Zyda 


DESC. : Contains routines machinepath and deletemachinepath for 
link creation/removal at a high level of abstraction. 


VERSION: 2.0 

DATE : 27 May 1987 

AUTHOR : Theodore H. Barrow 

DESC. : Converted to use a structure for ease of use. 
VERSION: 3.0 

DATE : 21 October 1987 

AUTHOR : Theodore H. Barrow 


* * *+ * * * © Be FH HH HH XA A He % EC CEC EC %* x #* % % HEHE HEH HEHE HH %* 03 %* CEC ASA 
* * * +*+ * * to x HH * * FH He HF E do dodo AA He X 


DESC. : Added function dynamicmachinepath to allow dynamic memory 
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* allocation after communications link established. * 
* * 
* VERSION: 4.0 $ 
* * 
^ DATE : 15 December 1987 ù 
* * 
* AUTHOR : Theodore H. Barrow : 
* * 
* DESC. : Added function dynamicmachinepaths to allow use with multiple * 
s links. Modified all creation routines to place sequence E 
3 numbers at end of command line for send and receive processes.* 
* * 
T VERSION: 5.0 * 
* * 
i DATE : 31 May 1988 * 
* * 
^ AUTHOR : Theodore H. Barrow + 
* * 
* DESC. : Added broadcast and receive capability - one process spawned * 
3€ e e e e e oe e e e e e je og oe oe ode ode ode oe e de oe oe ode oe de oe ode oe oe de ode ode e e e de oe ode o e e e e de 0 Dee de oe de oe e oe oe e e e e eo 
* * 
: RECORD OF CHANGES : 
* * 
*Version* Date * Author p i Al tected *Regd* 
> z Change Description * Modules "Vers: 
Hee e e e e e e e e e e e e e e e de de ode e e e ode e e e e e e e e e e e e oe oe e e e e e e e e e e e e e e e e e e e e e e ee e e e e KR RRR KK KR KK 
* * * * * * * 
* * * * * 


ROERO O A A OR OR oko o ok eoe dedo oe Roe oe oe / 


83 


mpath.c 


Kinclude "shared.h" /* my special defines */ 
#include <gl.h> 


deletemachinepath(instructure) 

Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 


int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 


int instructure.receivesem -- the returned receive semaphore. 
We base it on the receive portnumber. 


ki 
/* kill th€-receiver process...) 
kill_receiver(instructure->segment,instructure->receivesem); 


/* Kill the sender process... */ 
kill_sender(instructure->segment ,instructure->sendsem) ; 


/* detach and delete the shared segment... */ 
deletesharedsegnient(instructure->segment,instructure->shmid); 
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Ji 
For direct connection, both send and receive processes are spawned. 
For broadcast. either send or receive process is spawned. 
The machinepath routine performs the following: 
(1) creates a shared segment. 
(2) creates a send and/or receive semaphore based on the send and receive 
port numbers. ; 
(3) free_sender(segment) and/or free_receiver(segment) 
(4) spawns off the send and/or receive processes. 
system("send sharedseg# machinename port# server/client/broadcast 0&"): 
system("receive sharedseg# machinename port# server/client/receive 0&"); 
(5) the send and receive semaphores, the pointer to the shared segment, 
and the id of the shared segment are placed in a structure of type 
Machine that is declared in the calling program. 
n 


machinepath(segmentnum,mname, sendportnum,receiveportnum,server,instructure) 


long segmentnum; /* the key to use for the created shared segment */ 


char mname[]; /* machinename character string */ 

long sendportnum, receiveportnum; /* send and receive port numbers */ 

char server[]; Poetics character string is either sclient. “server”, 
"broadcast", or "receive". If direct connection wanted, 


it indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 
must be the server. If broadcast wanted, it indicates 
whether to open up as broadcaster or receiver. 


ny 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 
"I 
| ! 
char *sharedsegment(); /* shared segment creation function */ 
int semtran(); /* semaphore creating routine. */ 


char temp[200], temp2[200]; /* temp character arrays */ 
/* create the shared segment */ 
instructure->segment = sharedsegment (segment num,MAXSHAREDSIZE ,&instructure->shmid) ; 


/* create the send semaphore. (unused if receiving broadcast messages) */ 
instructure->sendsem = semtran(sendportnum) ; 


/* create the receive semaphore (unused if broadcasting messages) tel 
instructure->receivesem — semtran(receiveportnum); 


/* free the sender and receiver parts of the shared segment */ 
init shared buffer(instructure-»segment): 


/* spawn off the sender process */ 


1 


if( strcmp( server, "receive" ) l= 0.) 
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/* add the start of the line, ie. thefpros rano, 
strcpy(temp, SENDLOCATION) ; 


streat (temp. sum). 


/* add the number of the sharedsegment in text */ 
sprintf(temp2, "%d" ,instructure->shmid) ; 

streat( temp, temp2); 

strcat(temp," "); 


/* add on the machine name */ 
strcat(temp,mname); 
strcat(temp," "); 


/* add the port number */ 
sprintf(temp2,"%d",sendportnum); 
strcat(temp,temp2); 

strcat( tempo "); 


/* indicate whether a server, a client, or a broadcaster */ 
strcat(temp,server); 
strcat(temp,” 0"); 


/* spawn off into the background */ 
strcat(temp,"&"); 


/* spawn off the sender */ 
if( system(temp) == -1 ) 
perror("SEND system call failed"); 


else 


/* kill sender (which really doesn’t exist anyway) so that the 
sender_is_free() call will always return FALSE 
A similar thing does not have to be done for receiver_has_data() 
in a broadcasting path since it will always return FALSE anyway */ 
kill_sender( instructure->segment, instructure->sendsem ); 


/* spawn off the receiver process */ 


if( stremp( server, "broadcast" ) != 0 ) 

| 
/* add the start of the line, i.e. the program to run */ 
strcpy(temp, RECEIVELOCATION) ; 
strcat(temp," "); 


/* add the number of the sharedsegment in text */ 
sprintf(temp2,"%d",instructure->shmid); 
strcat(temp,temp2); 

strcat(temp," ”); 


/* add on the machine name */ 
strcat(temp,mname); 
strcat(temp," "); 


/* add the port number */ 
sprintf(temp2,"%d" ,receiveportnum) ; 
strcat(temp.temp2); 

Sica cen m1); 


/* indicate whether a server, a client, or a broadcast receiver */ 
strcat(temp, server); 
strcat(temp," 0"); 


/* spawn off into the background */ 
strcat(temp,"&"); 
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poan oll the receiver */ 
if( system(temp) == -1 ) 
perror( RECETE system call failed”); 
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I di 


For direct connection, both send and receive processes are spawned. 
For broadcast, either send or receive process is spawned. 
The dynamicmachinepath routine performs the following: 


(1) creates a shared segment and attaches it to the main program virtual 
space after an allocation of free memory space. 
(2) creates a send and/or receive semaphore based on the send and receive 
port numbers. 
) free_sender(segment) and/or free_receiver(segment) 
) spawns off the send and/or receive processes. 
system("send sharedseg# machinename port# server/client/broadcast 0&"); 
system("receive sharedseg# machinename port# server/clieut/receive 0%"); 
(5) the send and receive semaphores, the pointer to the shared segment, 
and the id of the shared segment are placed in a structure of type 
Machine that is declared in the calling program. 


T 


dynamicmachinepath(segmentnum,mname,sendportnum,receiveportnum,server, 
instructure,freespace) 


long segmentnum; /* the key to use for the created shared segment */ 


char mname[]; /* machinename character string */ 

long sendportuum, receiveportnum; /* send and receive port numbers */ 

char server[]; /* this character string ws either “ellient 3) server = 
"broadcast", or "receive". If direct connection wanted, 


it indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 


must be the server. If broadcast wanted, it indicates 
whether to open up as broadcaster or receiver. 
Di 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 
We base it on the receive portnumber. 
ij 
int freespace; /* amount of freespace desired for dynamic memory allocation 


after this routine has been called. */ 


char *dynamicsharedsegment(); /* shared segment creation function */ 
int semtran(); /* semaphore creating routine. */ 
char temp[200], temp2[200]; /* temp character arrays */ 


/* create the shared segment */ 
instructure->segment = dynamicsharedsegment(1,segmentnum MAXSHAREDSIZE, 


&instructure->shmid, freespace); 


/* create the send semaphore. (unused if receiving broadcast messages) */ 
instructure->sendsem = semtran(sendportnun); 


/* create the receive semaphore (unused if broadcasting messages) */ 
instructure->receivesem = semtran(receiveportnum); 
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tree the sender and receiver parts of the shared segment */ 
init. shared, buffer(instructure-»segment); 


/* spawn off the sender process */ 


" 


Eti stremp( server, "receive" ) !a O ) 


/* add the start of the line, i.e. the program to run */ 
strcpy(temp, SENDLOCATION) ; 
strcat(temp," "); 


/* add the number of the sharedsegment in text */ 
sprintf(temp2,"%d",instructure->shmid); 
strcat(temp,temp2); 

strcat(temp," "); 


/* add on the machine name */ 
strcat(temp,mname); 
sprcat(temp," "); 


/* add the port number */ 
sprintf(temp2, "god", sendportnum); 
strcat(temp,temp2); 
strcat(temp," "); 


/* indicate whether a server, a client, or a broadcaster */ 
strcat(temp,server); 
strcat(temp," 0&"); 


/* spawn off the sender into the background */ 
if( system(temp) == -l ) 
perror("SEND system call failed"); 
| 


else 


/* kill sender (which really doesn't exist anyway) so that the 
sender is free() call will always return FALSE. 
A similar thing does not have to be done for receiver has data() 
in a broadcasting path since it will always return FALSE anyway */ 
kill sender( instructure-»segment, instructure->sendsem ); 


/* spawn off the receiver process */ 


if( stremp( server, "broadcast" ) I= 0 ) 


| 


/* add the start of the line, i.e. the program to run */ 
strcpy(temp, RECEIVELOCATION) ; 


strcat(temp," "); 


/* add the number of the sharedsegment in text */ 
sprintf(temp2,"%d",instructure->shmid); 
strcat(temp,temp2); 

strcat(temp," "); 


/* add on the machine name */ 
strcat(temp inname ); 
strcat(temp," "); 


/* add the port number */ 
sprintf(temp2,"%d",receiveportnum); 
strcat(temp,temp2); 

strcat(temp," "); 


/* indicate whether a server, a client, or a broadcast receiver */ 


rca temp. server); 
strcat(temp," 0&"); 
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/* spawn off the receiver into the background */ 


if( system(übsnp) s m 
perror("RECEIVE system call failed"); 
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/ * 


For direct connection, both send and receive processes are spawned. 
For broadcast, either send or receive process is spawned. 
The dynamicmachinepaths routine performs the following: 


(1) creates a shared segment large enough for multiple attachments 
and attaches it to the main program virtual space after an allocation 
of free memory space. 
(2) creates a send and/or receive semaphore based on the send and receive 
port numbers. 
) free sender(segment) and/or free receiver(segment) 
) spawns off the send and/or receive processes. 
system("send sharedseg# machinename port# server/client/broadcast 0&"); 
system("receive sharedseg# machinename port# server/client/receive 0%”); 
(5) the send and receive semaphores, the pointer to the shared segment, 
and the id of the shared segment are placed in a structure of type 
Machine that is declared in the calling program. 


p 


dynamicmachinepaths(nummachines,segmentnum,mname,sendportnum,receiveportnum, 
server,instructure,freespace) 


int nummachines; /* the maximum number of other machines to be attached */ 


long segmentnum; /* the key to use for the created shared segment */ 


char mname[]; /* machinename character string */ 

long sendportnum, receiveportnum; /* send and receive port numbers */ 

char server[]; [*" tms character. string is either “client”, server’, 
"broadcast", or "receive". If direct connection wanted, 


it indicates whether the sender/receiver should open 
up as either a client or server. The first guy open 
must be the server. If broadcast wanted, it indicates 
whether to open up as broadcaster or receiver. 


i 
Machine *instructure; /* structure to hold segment and semaphore info: 
char *instructure.segment -- returned ptr to the shared segment. 
int instructure.shmid -- returned system generated shared mem id 
int instructure.sendsem -- the returned send semaphore. 
We base it on the send portnumber. 
int instructure.receivesem -- the returned receive semaphore. 
We base it on the receive portnumber. 
* f 
int freespace; /* amount of freespace desired for dynamic memory allocation 
after this routine has been calied. */ 
| 
char *dynamicsharedsegment(): /* shared segment creation function "/ 
int semtran(): /* semaphore creating routine. */ 
char temp[200], temp2[200]; /* temp character armays */ 


static Boolean firsttime = TRUE; /* flag to detect multiple requests */ 


static int sequencenum 0; /* sequence number for receive/send */ 
static int totmachines; /* max attachments permitted */ 


/* check for first time called and establish max possible attachments */ 
if( firsttime ) 
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totmachines = nunmachines; 
firsttime = FALSE; 

| 

else 
++sequencenum; 


/* check for violation of maximum attachments */ 
if( sequencenum >= totmachines ) 


perror("mpath: Too many attachments attempted"); 
cosi nca 


| 


/* create the shared segment */ 
instructure->segment = dynamicsharedsegment(nummachines,segmentnum, 
MAXSHAREDSIZE, 


&instructure->shmid, freespace); 


/* create the send semaphore. (unused if receiving broadcast messages) */ 
instructure->sendsem = semtran(sendportnum); 


/* create the receive semaphore (unused if broadcasting messages) */ 
instructure->receivesem = semtran(receiveportnum); 


/* free the sender and receiver parts of the shared segment */ 
init_shared_buffer(instructure->segment); 


/* spawn off the sender process */ 
if( stremp( server, “receive ) [= 0 ) 


/* add the start of the line, i.e. the program to run */ 
strcpy(temp, SENDLOCATION) ; 
strcat(temp," "); 


/* add the number of the sharedsegment in text */ 
sprintf(temp2, Tod" , instructure-»shmid); 
strcat(temp,temp2); 

strcat(temp," "); 


/* add on the machine name */ 
strcat(temp,mname); 
streat (temp, 055 


/* add the port number */ 
sprintf(temp2,"%d",sendportnum); 
strcat(temp,temp2); 
strcat(temp," "); 


/* indicate whether a server, a client, or a broadcaster */ 
strcat(temp,server); 

strcat(temp," "); 

/* add the machine sequence number */ 
sprintf(temp2,"%d",sequencenum); 

strcat(temp,temp2); 


/* spawn off into the background */ 
strcat(temp,"&"); 


/* spawn off the sender */ 
if( system(temp) == -l1 ) 
perror( "SEND system call failed"); 


else 


/* kill sender (which really doesn't exist anyway) so that the 
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sender_is_free() call will always return FALSE. 

A similar thing does not have to be done for receiver has data() 

in a broadcasting path since it will always return FALSE anyway */ 
kill_sender( instructure->segment, instructure->sendsem ); 


Pouespavn ort the receiver process "/ 
if( stremp( server, "broadcast" ) != 0 ) 


/* add the start of the line, i.e. the program to run */ 
strcpy(temp RECEIVELOCATION); 


strcat(temp," ”); 


/* add the number of the sharedsegment in text */ 
sprintf(temp2,"%d",instructure->shmid); 
strcat(temp,temp2); 

strcat(temp," "); 


/* add on the machine name */ 
strcat(temp,mname); 
strcat(temp," "); 


/* add the port number */ 
sprintf(temp2, Tod" , receiveportnum) ; 
strcat(temp, temp2); 

strcat(temp," ”); 


/* indicate whether a server, a client, or a broadcast receiver */ 
strcat(temp,server); 
strcat(temp," "); 


/* add the machine sequence number */ 
sprintf(temp2, "7d" , sequencenum) ; 
strcat(temp,temp2); 


/* spawn off into the background */ 
strcat(temp,"&"); 


/* spawn off the receiver */ 


if( system(temp) == -1 ) 
perror( "RECEIVE system call failed"); 


US 


3.  netV.c 


a. Calling Protocols 
This module contains the low-level socket-managing calls. No functions in 
this module are intended for application programs. This module is only linked into the 


send and receive processes. 


b. Code and Description 
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TITLE : Inter-Computer Communication Package 
MODULE : netV.c 
VERSION: 5.0 
DATE : 31 May 1988 
AUTHOR : Theodore H. Barrow 
FORO RIOR GIO KR OK IR o A A k o k a k RO OIOROR ION GIORGI C00 R00 X X0 ORO k k kok k kok k 
HISTORY : 
VERSION: 1.0 
DATE : 19 November 1986 
AUTHOR : Michael J. Zyda 


DESC. : Contains routines connect, server and connect. client to allow 
two machines with Unix System V to communicate via sockets. 


VERSION: 2.0 

DATE : 29 April 1987 

AUTHOR : Michael J. Zyda 

DESC. : Converted to work with 4.2BSD sockets. 

VERSION: 3.0 

DATE : 27 May 1987 

AUTHOR : Theodore H. Barrow 

DESC. .: Eliminated excess variables, some unused and some uunecessary. 
VERSION: 4.0 

DATE : 21 August 1987 

AUTHOR : Theodore H. Barrow 

DESC. .: Improved reliability of socket connection aud disconnection. 


VERSION: 5.0 
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DATE : 31 May 1988 
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* * 
* AUTHOR : Theodore H. Barrow r 
. * 
s DESC. : Added start broadcast() and broadcast receive() to provide * 
x datagram sockets for broadcast use. These sockets use the E 
* default Internet broadcast addressing. * 
co oe o oie ode o oe o oe oc o o oc o oc o oj oc oe oc oe ok ode oe ode oe o od ok ode oc o o oe o oc o ok oe oe oj ode o o oe o OOOO OOOO ORIO o oc o o o o X o o OR X OR X0 XC XG X0 He 
* a * 
* RECORD OF CHANGES T 
* * 
*Version* Date * Author * * Affected *Reqd* 
* A Change Description x Modules *Vers* 
x ode oe o oe ode oe o ode o o o o ode o o oe oe oco oe oe o oe oe ode ode oe oe ode ode o oe o oie oe ode o oe oj ode o ot ode ode oe ode ode oe oe ode od o oe oce o oe ode o oe oe ode o o ok oe o oe oe o o o oc oe oe oe oe de 
* 4.1 * 4Jan88 * T. H. Barrow * * send.c *4.0 * 
* * Changed include library pathnames for IRIS 4D.* receive.c *A4 0 * 
ecce od oe ode ode co o0 ode ode oe od ode oc o o o o oe o o o o oj OR ode oe ode oe oc oe o o ode oc ode o o o ok oe ode ode o oe ode o od od o o o o oe oj o o ok ok ok oe o oe ode ode o o oe oe ode oc o o 6 X X X0 Xx 
* * * “ke * * * 
* * * * * 
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JE 

This segment, when linked into a program on a computer with a UNIX 4.2 BSD 
operating system, will allow the program to communicate with programs 
executing on other computer systems over an Internet network. 


el 
#defiue TRUE | 


/* include files for UNIX 4.2 BSD. These are all called from the bsd 
subdirectory in /usr/include. The file sys/types.h also exists and is 
included when bsd/sys/types.h is used. This was done for ease of change 
if and when Silicon Graphics changes the include library structure. */ 

#include <sys/types.h> 

#include <sys/socket.h> 

#include <bsd/netinet/in.h> 

#include <bsd/netdb.h> 


OOOO k ok ooo o Rok OOOO ROO OOO ORO ORO OA AOIOROR ROIO A AIR ooo dolo kool 


The connect_server(remote_client_name, port_number) function performs 
the actions required to connect a server system to a remote client system 


TE 9 BRACE ARR AREA NARA RN E RR Re RR n 


int connect_server(remote_client_name, port_number) 


char remote_client_name[]; /* name of the remote client system */ 
int port, number; /* port number to the remote client system */ 
| 
char *ptr, client, name; /* pointer to the remote client system's name */ 
int local server socket; /* local socket number */ 
int socket(); /* function that opens a socket */ 
int accept(); /* function that accepts a connection from 


a remote client socket */ 
int remote client, socket - -1; /* socket number of remote client system */ 


/* protocol and address data structure for socket */ 


static struct sockaddr_in address = { AF_INET }; 

long remote_client_address; /* address of the remote client system */ 
short remote client port; /* port number of the remote client system */ 
int address size; /* size of address of remote client system */ 


/* create socket structure from input parameters */ 


/* get a pointer to the remote client system's name */ 
ptr_client_name = remote_client_name; 


/* convert the remote client system name to its address. 
Note that gethostbyname() requires a pointer to a pointer */ 
remote_client_address = (long)gethostbyname(&ptr_client_name); 


/* set the remote client port number above the system reserved ports 
by adding the remote client port number to the number of reserved ports */ 
remote client port —- IPPORT RESERVED 4* port number; 


/* remote client system address family (Internet in this case) */ 
address.sin family - AF INET ; 
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/* place the remote client port number into the address data structure 
in network byte order */ 
address.sin_port = htons(remote_client_port); 


/* place the remote client system's address in the address data structure */ 
address.sin_addr.s_addr = remote_client_address; 


/* find number of bytes in the remote client address */ 
address size = sizeof(remote client_address); 


/* attempt to open a local socket */ 


local server socket - socket(AF INET,SOCK, STREAM, 0) ; 


if(local. server socket « 0) 
perror("Server couldn't open a local socket:"); 
else 


| 


if(bind(local server socket, (caddr t)&address, sizeof(address)) < 0) 
perror("Server couldn't bind address to local socket:"); 


/* set the maximum number of remote client systems to be connected to */ 


listen(local server socket, SCMAXCONN) ; 
printf("Server waiting to connect to 9osNn",remote client, name); 


/* attempt to accept a connection */ 
remote client, socket - accept(local server socket, &address, 
&address size); 


if(remote client socket « 0) 


/* an error occurred in the server attempting to 
accept a connection from remote client system */ 
perror("Server couldn't accept connection from remote client system:"); 


shutdown(local server socket, 2); 
close(local, server, socket); 


| 


/* else the server accepted a connection from the remote client system */ 


) 


/* return the socket number of the remote client system */ 
return(remote client socket); 


) /* connect server */ 
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The connect_client(remote_server_name, port_number) function performs 
all the actions required to connect a client system to a remote server 
system 


3k oo IOIGICIGIOI keckeoke eode k Ro Rokok Gk do okeokokokokokoko ok k k | 


int connect client(remote server name, port number) 


char remote server name[]; /* name of the remote server system */ 
int port number; /* port number to the remote server system */ 
{ 

int local_client_socket; /* local socket number */ 

int socket(); /* function that opens a socket */ 


/* function that connects local socket to remote server socket */ 
int connect(); 


int remote server socket; /* socket number on remote server system  */ 


/* the protocol! and address data structure specified for the socket */ 
static struct sockaddr_in address = ( AF_INET }; 


struct hostent *remote_server_address; /* address of remote server system */ 


short remote_server_port; /* port number of remote system */ 
/* create socket structure from input parameters */ 


/* convert the remote server system name to its address. 
Note that gethostbyname() requires a pointer only in this case */ 
remote_server_address = gethostbyname(remote_server_name); 


/* clear out the address structure */ 
bzero((char *)&address, sizeof(address)); 


/* copy the remote server address structure into the address structure */ 
bcopy(remote server address-»h, addr, 

(char *)&address.sin, addr, 

remote server address-»h length); 


/* set remote server port number above the system reserved ports by adding 
the user's remote server port number to the number of reserved ports */ 
remote server port — IPPORT RESERVED 4 port number; 


/* remote server system address family(Internet in this case) */ 


address.sin family - AF INET; 


/* place the remote server port number into the address structure 
in network byte order */ 
address.sin_port = htons(remote server port); 


/* attempt to obtain a local socket */ 


local client socket - socket(AF INET, SOCK STREAM, 0); 


if(local client socket « O) 
perror("Client couldn't open a local socket: s 
else 


/* place Internet address family type in address structure */ 


address.sin family - AF INET; 


* 
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Cai tempimo connect local client socket to remote server socket */ 
remote_server_socket = connect(local_client_socket, (caddr_t )&address, 
sizeof(address)); 


if(remote_server_socket < 0) 


| 


Reitor occurred in attempting to connect to remote server socket */ 
Perroi Client coulda t conneci to ihe remote server socket”); 


shutdown(local_client_socket, 2); 
close(local_client_socket); 


/* set local_client_socket so that negative value is 
always returned when an error occurs 

T 

local client socket - remote server socket; 


| 


e liste 
successfu connecte o e remote server system 
[* fully ted to th t yst El 
printf("Connection established with %s.\n",remote_server_name); 


/* return the socket number of the local client system */ 
return(local_client_socket); 


} /* connect_client */ 
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[ RRR RERER EKER EEE RERE AE EEE EE EE Oe TT EE 


The start_broadcast(port_number) function performs 
the actions required to initiate a datagram broadcast socket. 


sk sie se oe oe ode heh sje he he he he oh e b coe e doo hoo oe o ake afe ae spele ae oke oke oke eo OK Roo E 


int start broadcast(port, number) 


int port number; /* port number for the remote receiver system */ 
| 
int broadcast socket; /* local socket number */ 
int socket(); /* function that opens a socket */ 
int setsockopt(); /* function that sets a socket to allow broadcast */ 
int on = TRUE; /* to set broadcast toggle on for socket */ 
/* protocol and address data structure for socket */ 
static struct sockaddr, in address = { AF INET }; 
short broadcast port; /* port number broadcast heard from */ 


/* create local socket structure from input parameters */ 


/* set the broadcast port number above the system reserved ports 
by adding the broadcast port number to the number of reserved ports */ 
broadcast. port - IPPORT RESERVED -* port, number; 


/* system address family (Internet in this case) */ 
address.sin family - AF INET ; 


/* place the port number into the address data structure 
in network byte order */ 
address.sin port - htons(broadcast port); 


/* place the local address in the address data structure 
in network byte order */ 
address.sin addr.s addr - htonl( INADDR ANY) ; 


/* attempt to open a local socket */ 
broadcast socket - socket(AF. INET,SOCK DGRAM, 0) ; 


if(broadcast socket « 0) 
perror("Broadcaster couldn't open a local socket:"); 
elise 


( 


/* set the broadcast_socket for broadcasting */ 
if(setsockopt( broadcast, socket, SOL SOCKET, SO BROADCAST, 
&on, sizeof(on) ) < 0) 
perror("Broadcaster couldn’t set socket to broadcast:"); 


else if(bind( broadcast_socket, (struct sockaddr *)&address, 
sizeof(address) ) < 0) 


perror("Broadcaster couldn't bind to local socket:"); 
else 


printf( "Waiting to broadcast\n"); 
| 
/* return the socket number */ 


return(broadcast socket); 


| /* start broadcast */ 
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[IAA AAA AAA AA AIA AAA AAA AIA I AIA AIR AAA AIR AAA AAA RA AR AC AO AAA AH 


The broadcast_receive(broadcaster_name,port_number) function performs 
all the actions required to set up a broadcast receiving socket 


1 AAI AIA IAA AIA AAA AI IAAAAI AAA AA IAA AAA III AIA AA AA AIA AIA AAA RA AAA] 


int broadcast_receive(broadcaster_name,port_number) 


char broadcaster name[]; /* name of the broadcaster system */ 
int port number; /* port number for the broadcaster */ 
| 

int local socket; /* local socket number */ 

int socket(); /* function that opens a socket */ 


int broadcaster_socket; /* socket number on broadcaster system */ 


/* the protocol! and address data structure specified for the socket */ 
static struct sockaddr_in address = { AF_INET }; 


struct hostent *broadcaster_address; /* address of broadcaster system */ 


short broadcaster_port; /* port number of remote system */ 
/* create socket structure from input parameters */ 


/* convert the broadcaster system name to its address. 
Note that gethostbyname() requires a pointer only in this case */ 
broadcaster_address = gethostbyname(broadcaster_name); 


/* clear out the address structure */ 
bzero((char *)&address, sizeof(address)); 


/* copy the broadcaster address structure into the address structure */ 
bcopy(broadcaster_address->h_addr, 

(char *)&address.sin_addr, 

broadcaster_address->h_length); 


/* set broadcaster port number above the system reserved ports by adding 
the user's broadcaster port number to the number of reserved ports */ 
broadcaster port —- IPPORT RESERVED + port number; 


/* broadcaster system address family(Internet in this case) */ 
address.sin, family = AF_INET; 


/* place the broadcaster port number into tlie address structure 
in network byte order */ 
address.sin port — htons(broadcaster port); 


/* attempt to obtain a local socket */ 
local socket 2 socket(AF INET, SOCK DGRAM, 0); 


if(local socket « O) 


| 
) 


else 


perror( Receiver couldn’t open a local socket:"); 


/* attempt to connect local socket to broadcaster socket */ 
broadcaster_socket = connect(local_socket, (struct sockaddr *)&address, 
sizeof(address)); 


101 


netV.c 


if(broadcaster_socket < 0) 


| 


/* error occurred in attempting to insert broadcaster information */ 
perror("Receiver couldn't find broadcaster: 7); 


shutdown(local, socket, 2); 
close(local, socket); 


/* set local, socket so that negative value is 
always returned when an error occurs 

si 

local_socket = broadcaster_socket; 


else 
/* successfully listening to the broadcaster system */ 
printf("ready to receive from %s.\n",broadcaster_name) ; 


) 


/* return the socket number of the local system */ 
return(local_socket); 


) /* broadcast receive */ 
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4.  receive.c 


a. Calling Protocols 
This program monitors a socket, like a daemon. It 1s spawned transparently to 


the user and receives its initialization data through the command line. 


b. Code and Description 
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TITLE : Inter-Computer Communication Package 
MODULE : receive.c 
VERSION: 3.0 
DATE : 31 May 1988 
AUTHOR : Theodore H. Barrow 
1 AIA IA do o dedo dodo IO ak k ae Ae ak ae A Ae ak ak k ae ae ae ak a ak akk ak ak ake a k ak ake ake e ae ae ak Ae ak ak a ak a ak ake ak AAA AAA AAA AA AAA 
HISTORY: 
VERSION: 1.0 
DATE : 6 February 1987 
AUTHOR : Michael J. Zyda 
DESC. : Background process to receive messages over link. 
VERSION: 2.0 
DATE : 15 December 1987 
AUTHOR : Theodore H. Barrow 


DESC. : Added capability to get sequence number from command line 
and use it to get offset into shared memory segment. 


VERSION: 3.0 
DATE : 31 May 1988 
AUTHOR : Theodore H. Barrow 
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DESC. : Added broadcast receive capability 
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tinclude "shared.h" 
#include "gl.h" 


main(argc,argv) 
int argc; /* argument count */ 
charagsargv0; /* pointers to the passed in arguments */ 


| 


/* we need to declare character variables for everything passed in */ 


char shmidstr[10]; /* shared segment string holding the integer key*/ 
int shmid; /* integer pulled out of the string */ 

char *segment; /* character pointer to the shared segment */ 

int receivesem; /* receive semaphore */ 


char *sharedsegment();/* create shared segment function */ 


char mname[ 100]; /* machine name */ 

char portstr[10]; /* port number string */ 

long portnum; /* port number pulled from the string */ 

char server[10]; f* server string '/ 

char seqnostr[10]: /* sequence # string holding integer sequence # */ 


long sequencenum = 0; /* integer pulled out of the string (default 0) */ 
int socket: /* the opened socket descriptor */ 

int connect_server(); 

int Sine eno 

int broadcast receive(); 

int receiver is free(); 

int receiver should die(); 

int semtran(); /* semaphore creation routine. */ 

/* pull out the strings from the argument list */ 


if(argc « 5) 

| 
printf("RECEIVE: incorrect argument count!\n"); 
exit(1); 


| 


/* pull out the shared memory string */ 
strcpy(shmidstr,argv[1]): 
sscanf(shmidstr, "od" , &shmid) ; 


/* pull out the machinename string */ 
strcpy(mname ,argv[2]); 


/* pull out the port number string */ 


strcpy(portstr,argv[3}); 
sscanf(portstr,"%d" ,&portnum) ; 
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¡ea Le ¡ie receive semaphore */ 
receivesem = semtran(portnum): 


/* pull out the client/server string */ 
strcpy(server,argv[4]); 


/* pull out the sequence number string */ 
if( argc > 4 ) 


strcpy(segnostr,argv[5]); 
sscanf(segnostr,"%d" &sequencenum); 


) 


/* attach to the shared memory segment */ 
if((int)(segment = (char *)shmat(shmid, 0, 0666)) < 0) 


| 
perror( "RECEIVE: shmat") ; 
exit(0); 

) 


/* create the shared segment address to use */ 


segment += sequencenum * MAXSHAREDSIZE; 


/* open the socket connection to the named machine */ 
if(strcemp(server,"server") == 0) 


/* we should open as the server */ 
socket = connect_server(mname,portnum); 


else if(strcmp(server, receive") == 0) 
/* we should open as the broadcast receiver*/ 
socket = broadcast_receive(mname,portnum); 


else 


/* we should open as a client */ 
socket = connect_client(mname,portnum); 


/* check to make sure socket was opened, exit if not */ 
if(socket < 0) 


| 
printf("RECEIVE: socket connection NOT made! n"); 


exit(1); 
} 
the infinite loop... */ 
if(stremp(server,"receive") == 0) 
while(TRUE) 


| 


/* should the receiver die??? */ 
if(receiver should die(segment,receivesem)) 
( 
/* exit after detaching shared segment and cleaning up socket */ 
detachsharedsegment(segment); 
shutdown( socket, 0); 
close(socket); 
exit(0); 


) 


it “the receiver part of the segment 1s free, read onto 1t */ 
ijliignecelvertis free(sepment)) 


/* check socket and read into segment if proper message */ 
if(broadcast into segment(socket,segment,mname,portnum) » 0) 
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/* at this point, sleep until we receive a signal from the 
graphics program that the receiver segment is free, i.e. 
the data has been read out */ 

P(receivesem); 


} /* end while true for broadcasting*/ 
else 


wh i le (TRUE) 
( 


/* should the receiver die??? */ 
if(receiver should die(segment,receivesem)) 
( 
/* exit after detaching shared segment and cleaning up socket */ 
detachsharedsegment(segment); 
shutdown(socket, 0); 
close(socket); 
exit(0); 
| 


/* if the receiver part of the segment is free, read onto it */ 
if(receiver is free(segment)) 
{ 
/* read socket into segment */ 
read_socket_into_segment(socket,segment); 


| 


/* at this point, sleep until we receive a signal from the 
graphics program that the receiver segment is free, i.e. 
the data has been read out */ 

P(receivesem); 


} /* end while true for direct connections*/ 
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5. semaphore.c 


a. Calling Protocols 
This module repackages the low-level semaphore calls into a P and a V 


semaphore operation. No functions in this module are intended for application programs. 


b. Code and Description 
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TITLE : Inter-Computer Communication Package 
MODULE : send.c 

VERSION: 1.0 

DATE : 11 February 1987 

AUTHOR : Michael J. Zyda 
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HISTORY: 
VERSION: 1.0 
DATE : 11 February 1987 


AUTHOR : Michael J. Zyda 
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DESC. : Implements P and V semaphore operations for Unix system V. 
Based on an example from Advanced Unix Progranming. 
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#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/sem.h> 


int semtran(key) /* translate semaphore key to ID */ 
int key; 
( 


int sid: 


if ((sid = semget((key_t)key,1,06661 IPC _CREAT)) == -1) 
| 
perror("semget"); 


| 


return(sid); 


static void semcall(sid,op) /* call semop  */ 
int sid; 
int op; 


| 
struct sembuf sb; 
sb.sem num = 0; 
sb.sem_op = op; 
sb.sem_flg = U; 
if(semop(sid,&sb,1) == -1) 
{ 


perror("semop"); 


void P(sid) /* acquire semaphore  */ 
int sid; 


{ 
) 


semcall(sid, -1); 


void V(sid) /* release semaphore */ 
int sid; 


{ 
) 


semcall(sid, 1); 
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6. Ssend.c 


a. Calling Protocols 
This program monitors a socket, like a daemon. It is spawned transparently to 


the user and receives its initialization data through the command line. 


b. Code and Description 
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TITLE : Inter-Computer Communication Package 
MODULE : send.c 

VERSION: 3.0 

DATE : 31 May 1988 

AUTHOR : Theodore H. Barrow 
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VERSION: 1.0 

DATE : 6 February 1987 

AUTHOR : Michael J. Zyda 

DESC. : Background process to send messages over link. 
VERSION: 2.0 

DATE : 15 December 1987 

AUTHOR : Theodore H. Barrow 


DESC. : Added capability to get sequence number from command line 
and use it to get offset into shared memory segment. 


VERSION: 3.0 
DATE : 31 May 1988 
AUTHOR : Theodore H. Barrow 
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DESC. : Added broadcast capability 
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#include "shared.h" 
#include "gl.h" 


main(argc,argv) 


int 


arge /* argument count */ 


char *argv[]; /* pointers to the passed in arguments */ 


| 


/* we need to declare character variables for everything passed in */ 


char shmidstr[10]; /* shared segment string holding the integer shmid */ 
int shmid; /* integer pulled out of the string */ 

char *segment; /* character pointer to the shared segment */ 

int sendsem; /* send semaphore */ 


char *sharedsegment();/* create shared segment function */ 


char mname[ 100]; /* machine name */ 

char portstr{10]; /* port number string */ 

long portnum; /* port number pulled from the string */ 

char server[10]; [* server string "/ 

char seqnostr[10]; /* sequence # string holding integer sequence # */ 


long sequencenum = 0; /* integer pulled out of the string (default 0) */ 


int socket; /* the opened socket descriptor */ 


int connect_server(); 
int connect_client(); 
int start_broadcast(); 
int sender_has_data(); 


int sender_should_die(); 


int semtran(); /* semaphore creation routine. 


/* pull out the strings from the argument list */ 
if(argc « 5) 
| 
printf( "SEND: incorrect argument count!\n"); 
exit(1); 
| 
/* pull out the shared memory string */ 
strcpy(shmidstr,argv[1]):; 
sscauf(shnmidstr, "Tod" ,&shmid) ; 


/* pull out the machinename string */ 
strcpy(mname,argv[2]); 


/* pull out the port number string */ 
strepy(portstr,argv[3]); 
sscanf(portstr,"%d" ,&portnum) ; 


/* create the send semaphore */ 
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sendsem = semtran(portnum); 


/* pull out the client/server string */ 
Strcpy({server,argv[4]); 


/* pull out the sequence number string */ 
if( arge > 4 ) 
| 
strcpy(seqnostr,argv[5]): 
sscanf(seqnostr, "Tod" ,&sequencenum); 


| 


/* attach to the shared memory segment */ 
if((int)(segment = (char *)shmat(shmid, 0, 0666)) < 0) 
( 

perror("SEND:shmat"); 

ExIL OD). 
) 


ere ate the shared segment */ 
segment += sequencenum * MAXSHAREDSIZE; 


/* open the socket connection to the named machine */ 
i stremp(server, server ) == 0) 


/* we should open as the server */ 
socket = connect_server(mname,portnum); 


else if{ stremp{ server, "broadcast" ) == 0 ) 


/* we should open as a broadcaster */ 
socket = start_broadcast( portnum ); 
) 
else 
| | 
¡e should open as a clicat */ 
socket = connect_client(mname,portnum); 


/* check to make sure socket was opened, exit if not */ 
if(socket < 0) 
{ 

printf("SEND: socket connection NOT made!\n"); 

exit tl): 


/* the infinite loop... */ 


if( stremp( server, "broadcast" ) == 0 ) 
while( TRUE) 
{ 
/* should the sender die??? */ 
if(sender_should die(segment,sendsem)) 
| 
/* exit after detaching segment and cleaning up socket */ 
detachsharedsegment(segment); 
shutdown(socket, 1); 
close(socket); 
ex1t(0); 
| 


/* 1f there is data in the shared memory segment. ... */ 
if(sender has data(segment)) 


/* write the data in the shared segment onto the socket */ 
send socket from segment(socket,portnum,segment); 
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/* at this point, sleep until we receive a signal from the graphics 
program. The signal will indicate that the graphics program 
has put more data into the shared segment. 

b 


P(sendsem); 


/* end while true for broadcasting*/ 
else 


wh i le( TRUE) 


/* should the sender die??? */ 
if(sender_should_die( segment , sendsem) ) 
{ 
/* exit after detaching segment and cleaning up socket */ 
detachsharedsegment(segment); 
shutdown(socket, 1); 
close(socket); 
ex1t(0); 
} 


/* if there is data in the shared memory segment, ... */ 
if(sender_has_data(segmnent)) 


| 


/* write the data in the shared segment onto the socket */ 
write_socket_from_segment(socket,segment); 


| 


/* at this point, sleep until we receive a signal from the graphics 
program. The signal will indicate that the graphics program 
has put more data into the shared segment. 

= 

P(sendsem); 


) /* end while true for direct connection*/ 
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7. shared.h 


a. Calling Protocols 
This module has all the predefined constants and type definitions. It must be 


included in the application. 
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b. Code and Description 


] 5 Reese ee o oe desee ook ook EERE EET ERR OT ee eee 
* * 
* TITLE Inter-Computer Communication Package t 
* * 
* MODULE shared.h T 
* * 
* VERSION: 4.0 * 
* * 
* DATE 15 December 1987 : 
* * 
* AUTHOR : Theodore H. Barrow * 
* * 
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* * 
* HISTORY: * 
x * 
t VERSION: 1.0 * 
x * 
z DATE 6 February 1987 * 
x * 
È AUTHOR : Michael J. Zyda È 
xk * 
È DESC. Contains all defines and special constants for shared = 
* memory socket system. 4 
* * 
* VERSION: 2.0 i 
+ * 
$ DATE 27 May 1987 3 
* * 
- AUTHOR : Theodore H. Barrow * 
* * 
r DESC. : Added a typedef of structure for use by various routines. t 
ña Added message types for high level read/write protocol. * 
* * 
* VERSION: 3.0 n 
x * 
È DATE 21 October 1987 x 
* * 
7 AUTHOR : Theodore H. Barrow + 
* * 
7 DESC. Changed dependencies of buffer calculation constants so that * 
T only one need change. Added additional message types. 1 
* * 
* VERSION: 4.0 : 
* * 
E DATE 15 December 1987 * 
* * 
x AUTHOR : Theodore H. Barrow n 
* * 
* DESC. Added field to buffer set so that each link would have its * 
T own area to handle partial receipt of messages. È 
x oe oe ode oe oe o oe oe ee e ote ote e te oe oe oe ote ote ote ote ote ote ate ate oe ete oe ote te oe oe ode oe e e eo 
* * 
* RECORD OF CHANGES E 
* * 
*Version* Date * Author t * Afteected *Regd* 
A x Change Description * Modules NV Cone 
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* 4.1 * 4Jan88 * T. H. Barrow * x * * 
* * Changed pathname to include /usr for IRISI * : 


5 ok O de oe he ho e o SORA ACI RAI A A ok do o E R0 RR XR XR o o o o0 ok k k k k k o ok o k k k k k k / 
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ym 


the following 3 defines are the changeable parameters 


LARGESTREAD MJST be divisible by 4 
* 


#de fine SENDLOCATION "/usr/work/barrow/share3/send" /* the name of the program 
to run for the sender */ 


#define RECEIVELOCATION "/usr/work/barrow/share3/receive" /* the name of program 


to run for the receiver */ 


#define LARGESTREAD 252 joie arrestado. butter size] */ 


/* The following defines are constants or are derived from LARGESTREAD */ 

#de fine SENDEROFFSET (LARGESTREAD 4 4) /* the sender data starts here */ 

define WSENDEROFFSET (SENDEROFFSET / 4) /* long word offset for sender data */ 

#define RECEIVEROFFSET 0 j* the receiver datå starts at byte O */ 

#def ine WRECEIVEROFFSET O0 /* the receiver data starts at long word O */ 

#define PROTOCOLHOLDOFFSET (SENDEROFFSET * 2) /* holding area starts after 
sender area */ 


#define MAXSHAREDSIZE (PROTOCOLHOLDOFFSET + i2) /* the number of bytes in the 


shared segment */ 


«define CHARACTER TYPE 'B' /* code for characters */ 
define INTEGER TYPE "I° /* code for integers */ 

#define FLOAT TYPE 'R' /* code for floats */ 

#define CHARACTER_ARRAY TYPE ‘°C’ /* code for character arrays */ 
#define INTEGER_ARRAY TYPE MJ /* code for integer arrays */ 
Sdefine FLOAT ARRAY TYPE 'S'  f* code for float arrays */ 
Hdefine CHARACTER SIZE 1 /* character size in bytes */ 
Hdefine INTEGER SIZE sizeof(1) m nteger size in bytes */ 
#define FLOAT_SIZE sizeof 0O) “float size in bytes */ 


/* the following is the structure type definition needed for each machine 
you want to conmunicate to... 


of 
typedef struct { 
char *segment; /* ptr to shared memory segment */ 
int shmid; /* system generated shared mem. id */ 
int sendsem; /* semaphore used to wakeup the sender 
process. 
n 
int receivesem; /* semaphore used to wakeup the 


receiver process... 
S 
) Machine ; 
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9. shareseg.c 


a. Calling Protocols 
This module contains the low-level shared-memory calls. No functions in this 


module are intended for application programs. 


b. Code and Description 


[FREER EE EEE EERE EE EEE ET REE ET TE EE ee ee 
* * 
* TITLE : Inter-Computer Communication Package * 
X * 
* MODULE : shareseg.c * 
* * 
* VERSION: 3.1 * 
* * 
* DATE : 24 February 1988 " 
* * 
* AUTHOR : Theodore H. Barrow * 
x * 
s sje ce je ode obe ke obe oe ope oe je ote oe oie fe ole e te ate ode ode ate je oie obe je obe cde obe obe je oe je ke je je ok je ke ok ok oe oe oi ok oe ke ke ode OR e ok he je nhe He te he te je oe e ose sje ode oe ke sje sje ate oe oe e ee oe 
Es * 
* HISTORY: £ 
* + 
: VERSION: 1.0 * 
È * 
E DATE : 6 February 1987 T 
* * 
È AUTHOR : Michael J. Zyda x 
* * 
E DESC. : Contains routines to manage shared memory segment. Creation * 
* attachment, detachment and deletion are all covered. * 
* * 
: VERSION: 2.0 * 
* * 
E DATE : 21 October 1987 : 
+ * 
* AUTHOR : Theodore H. Barrow * 
* * 
* DESC. : Added function dynamicsharedsegment to allow dynamic memory * 
È allocation after communications Îink established. * 
* * 
: VERSION: 3.0 * 
+ + 
= DATE : 15 December 1987 * 
* * 
" AUTHOR : Theodore H. Barrow 5 
* * 
. DESC. : Modified function dynamicsharedsegment for use with multiple * 
z links. First call does shared segment creation. Subsequent  * 
x calls return address for the next buffer set. * 
He He e oe oe He ote ole ole ate fe te pe fe te he ade ode ade ade te te te ae ie oe ae ate ode je je oie ode je je oie ode ok ate ke je spe e ate sje fe ae fe je ae e je pe te ate sje oke ode oke sje je ete he ee ee ee ek OKO OK OK 
* * 
x RECORD OF CHANGES z 
* * 
*Version* Date * Author * * Affected *Reqd* 
* È Change Description * Modules “Ves 
» ode ode e fe ade ae e e k ode ode e fe oe ae ole ode fe te je ste ode je e e ae ae e ode ae ae ae ae ode ate ae te oe e e e fe fe ose e ode fe fe ote e e ke ke e ke ke oie ke oe je je ke oie e ae le e ae oe e ade de ae de He ok fe 
* 3.1 * 24Feb88* T. H. Barrow * * none T : 
* * Added compatibility for IRIS 4D. 4 * * 


I ACACIA AIA IA AAA AIA IR AAA e de joke ok E e oo oce de e de oe e he de o e le o o oe o o ode o de dee e e e e e eoo oed edo eese / 
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#include <sys/sysmacros.h> 
#include <stdio.h> 
#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/shm.h> 
#include <gl.h> 


/* The following defines will have to be modified for different machines 
but one of the underlying shared memory attachment mechanisms should 
work for any system V implementation. */ 

#define IRIS4D 1 

#de fine IRIS3000 2 


#ifdef FLAT 

#de fine MACHINE IRIS4D 
Helse 

#define MACHINE  IRIS3000 
#endif 


char *sharedsegment(key,nbytes, shmid) 
long key; /* the key to use for the segment */ 


long nbytes; /* the number of bytes in the segment */ 


int *shmid; /* returned shared memory id name */ 
í 
char *buf; [* temp char pointer */ 
struct shmid ds junkbuf; /* I don't care what's in this buffer */ 


/* allocate a shared memory segment */ 
if( (*shmid = shmget( key, nbytes, 0666 1! IPC_CREAT )) < 0 ) 
| 
perror("shmget"); 
exit(0); 
) 


/* attach to the shared memory segment */ 
if((int)(buf = (char *)shmat(*shmid, 0, 0666)) < 0) 
{ 


perror("shmat"); 


/* Since there was an attachment error, delete the segment */ 
if( shmetl( shmid, IPC_RMID, &junkbuf ) == -1 ) 
perror( "shmctl" ); 
exit(0); 
) 


/* return the pointer to the shared segment */ 
return(buf); 
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char *attach_within_datasegment( key, size, shmid, freespace ) 


long key: /* the key to use for the segment */ 
long size: /* the number of bytes in the segment */ 
int *shmid; /* returned shared memory id name */ 
int freespace; /* amount freespace desired for dynamic allocation */ 
| 
char *enddata, *buf; /* temporary address pointers */ 
struct shmid_ds junkbuf; /* I don’t care what's in this buffer */ 


char *sbrk(), *malloc(); 


/* allocate a shared memory segment */ 
if( (*shmid = shmget(key, size, 0666 |! IPC_CREAT)) < 0 ) 
( 

perror("shmget"); 

exit(0); 


/* Ensure at least as much unallocated space as freespace indicates. 
Normally the top of the data region is incremented more than the 


minimum required to meet the malloc() request. Using malloc() 

and free() ensures that this mechanism is available for subsequent 
dynamic memory allocations. Direct use of sbrk() system call 
causes the malloc() mechanism to fail on subsequent allocation 
requests. freespace is cast to unsigned to meet malloc() spec. */ 


free( malloc( (unsigned)freespace )); 


/* find the top of data region */ 
enddata = sbrk(0); 


/* round up to the next page boundary for attachment of shared 
memory segment */ 


buf = (char *)((int)enddata - ((int)enddata % SHMLBA) + SHMLBA); 


/* reset top of data region to be above shared segment */ 
if( brk( buf + size ) < 0 ) 


( 
perror("brk"); 


/* Since there was an error, delete the segment */ 


if( shmctl( shmid, IPC_RMID, &junkbuf ) == -1 ) 
perror( “shmetl" ); 
exit(-1); 


| 


/* attach to the shared memory segment at the calculated address */ 
if( (int)shmat(*shmid, buf, 0666) « O ) 
| 


perror("shmat"); 


/* Since there was an attachment error, delete the segment */ 


if( shmctl( shmid, IPC RMID, &junkbuf ) -- -1 ) 
perror( "shmct!" ):; 
exit(0); 


) 
return( buf ); 


) /* attach within datasegment() */ 
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char *dynamicsharedsegment(nummachines, key, nbytes, shmid, freespace) 


int nunmachines; /* maximum number of machines to be initiated */ 


long key: /* the key to use for the segment */ 
long nbytes: /* the number of bytes in the segment */ 
int *shmid; /* returned shared memory id name */ 
int freespace; /* amount freespace desired for dynamic allocation */ 
| 
static Boolean firsttime = TRUE; /* allows for multiple calls */ 


static char *startshared; /* start of shared memory space */ 
static int *holdshmid; /* holds shmid for subsequent calls */ 


if( firsttime ) 


| 
switch( MACHINE ) 


case IRIS4D: 
startshared = sharedsegment( key, nummachines*nbytes, shmid ); 
break; 

case IRIS3000: 
startshared 


(char *)attach, within, datasegment( key, 
nummachines*nbytes, shmid, freespace ); 
break; 
default: 
perror( "shareseg: Unknown machine" ); 


) /* switch( MACHINE ) */ 


holdshmid = shmid; 
firsttime = FALSE; 
) 
else 
{ 
/* start next buffer immediately above last. Return the same shmid 
for all buffers. Assumes all buffers are same size (true if all 


from same shared.h definition. */ 
startshared += nbytes; 


*shmid = *holdshmid; 


| 
/* return pointer to the proper buffer in the shared segment */ 
return( startshared ); 
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detachsharedsegment(segment) 


char *segment; /* segment to detach from */ 


| 


int returnvalue; 


if( (int)segment % SHMLBA != 0 ) 
return( | ); 
else 
| 
if( returnvalue - shmdt(segment) « O ) 
perror("shmdt"); 
return( returnvalue ); 


deletesharedsegment(segment , shmid) 


char *segment; /* character pointer to the shared segment */ 


int 


í 


shmid; /* shared memory id... */ 


int returnvalue; 
struct shmid_ds junkbuf; /* I don't care what's in this buffer */ 


/* detach from the shared segment and set returnvalue */ 
if( returnvalue = detachsharedsegment(segment) == 0 ) 


/* remove the shared segment from the system and reset returnvalue */ 
if( returnvalue = shmcti(shmid, IPC_RMID, &junkbuf) < 0 ) 
perror("shmct 1"); 


return(returnvalue); 
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9.  support.c 


a. Calling Protocols 


This module contains functions that are intended for the application’s use and 


functions that are used exclusively by other routines. The parameters for externally 


accessible functions are described below. 


i. receiver has data 


int receiver has data(instructure) 


Machine *instructure; /* includes 
char *instructure.segment 


ii. sender is-free 
int sender_is_free(instructure) 


Machine *instructure; /* includes 
char *instructure.segment 
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to the shared segment */ 
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d 
* 
* 
« 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
k 
* 
* 
x 
* 
* 


support.c 


b. Code and Description 


x ok oie k k oie oie oie oic oie oe oe oie oie oie oie oic oie oie oe oe oe oie oie aie oe oie ok oic ok oc oke oc oie oc ole oie oic ok o oie oe okc ok oe oe oic oc oie oc ok oic okc occ oic oc ok oc oc oic oc oic o oco oe oe oe oc oc o oc oe XC OG OG X 


TITLE Inter-Computer Conmunication Package 
MODULE support.c 

VERSION: 4.0 

DATE 31 May 1988 

AUTHOR : Theodore H. Barrow 


HISTORY: 


VERS ION: 


DATE 
AUTHOR 
DESC. 


VERS ION: 


DATE 
AUTHOR 
DESC. 


VERS ION: 


DATE 
AUTHOR 
DESC. 


VERS ION: 


DATE 
AUTHOR 
DESC. 


3 se e je ode oe je ade oe oe oe oe oe oe oe oc oe je sje ok oe ode je oe oe oe oe je ade ok ode ode oc oie oc e oc sie ok oe je oe oe ode oc oie oe sje aie oco oe X oe oe o oe oie ke Ae ak ake oj oe oc ocoke oc oe oe oc oco oe 


1.0 
6 February 1987 
Michael J. Zyda 


Contains 
System. 


support routines for shared memory conmunications 


2:0 
27 May 1987 
Theodore H. Barrow 


Converted functions called by the application program to use 
a structure for ease of use. 


3.0 
21 October 1987 
Theodore H. Barrow 


Removed functions for reading from and writing to the shared 
memory segment by the application program. 


4.0 
31 May 1988 
Theodore H. Barrow 


Added functions broadcast, into segment and 


send socket from segment for broadcasting over datagram socket 
3 oe oj oe okc ok oxkc oe oc oie ok ox obe oe ox o oe oko X o ok oe pe ox oe obe ok obe obe o oe oe oj oe oe oie oe oie ok ok obe oe je oe oe oe ode oe oc oe oie oe oc oe oie oe ope obe oe oe oe ope ode oic oe oie ok ok oe ook oe o ox o e x 


Y Y E E Y E E A A A SF 


+ 3X 048 * * E E E E E E E E FE HHA EER E E è* E E %* E 


* 

RECORD OF CHANGES T 

* 

*Version* Date Author E * Affected *Reqd* 

* y Change Description * Modules *Vers* 
3 o ke oe oe ole e oe oie oc oe oc ke he oe oe oc oc oleo oc oc Dc de e ae oic oc oe oe o e ole oc e ae oie oic oc oie ie a a oc e o oe oc o e oe ae oic oc oc oe k o oe o oc ok oc oc oc oc ke ok k k ok o e o Se 

* * * * * * * 

* * * * * 
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#include "shared.h" 
include <gl.h> 

include <bsd/sys/types.h> 
include «sys/socket.h» 
include «bsd/netinet/in.h» 
#include <bsd/netdb.h> 


/* the following routine sets up buffer area */ 
init_shared_buffer(segment) 


char *segment; /* pointer to the shared segment */ 


| 


Bree sender( segment ); 
nee receiver( segment ); 
*(segment + PROTOCOLHOLDOFFSET + 9) = “\0°; 


/* the following routine writes zeroes at the top of the 


shared segment indicating that the segment data is no longer 
valid. 


E 
free sender(segment) 


char *segment; /* pointer to the shared segment */ 


| 
/* the following line zeroes the first four bytes of the sender part 
of the shared memory segment. ’segment’ is a character pointer. 
I coerce it into a long integer pointer and then write a zero. 
pi 
*((long *)segment + WSENDEROFFSET) = 0; 


/* this following routine writes zeroes at the top of the 
shared segment indicating that the segment data is no longer 
valid. 


a 
free receiver(segment) 


char *segment: /* pointer to the shared segment */ 


| 
/* the following line zeroes the first four bytes of the receiver part 
of the shared’ memory segment. ‘segment’ is a character pointer. 
I coerce it into a long integer pointer and then write a zero. 
nn 
*(( long *)segment + WRECEIVEROFFSET) = 0; 
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/* the following routine tests the first 4 bytes of Thente canen 
segment to see ey are non Zero. 
it uses an input structure since called by main program 


ey 
int receiver_has_data(instructure) 
Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment */ 


if(*(( long *)instructure->segment + WRECEIVEROFFSET) > 0) 
| 


else 


return( TRUE) ; 


return(FALSE) ; 


/* the following routine tests the first 4 bytes of the sender 
segment to see if they are non-zero. 


E 
int sender has data(segment) 
char *segment; /* pointer to the shared segment */ 


| 


if(*((long *)segment + WSENDEROFFSET) > 0) 
| 


} 
else 


| 


return( TRUE) ; 


return(FALSE); 
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E [olVowing routine tests the frrst 4 bytes of the receiver 
s segment to see if they are less than zero. 
int receiver should die(segment) 
char *segment: /* pointer to the shared segment */ 
| 
if(*((long *)segment + WRECEIVEROFFSET) < 0) 
| return( TRUE); 


else 


| 
) 


return(FALSE); 


/* the following routine tests the first 4 bytes of the sender 
segment to see if they are less than zero. 


n; 
int sender_should_die(segment) 
char *segment; /* pointer to the shared segment */ 
| 
if(*((long *)segment + WSENDEROFESET) < 0) 
| return( TRUE); 
ite 


| 


return( FALSE) ; 
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/* the following routine tests the first 4 bytes of the receiver 
segment to see if they are non-zero. 


e 
int receiver is free(segment) 


char *segment: /* pointer to the shared segment */ 


if(*((long *)segment + WRECEIVEROFESET) == 0) 
{ 


return(TRUE): 
) 


else 


| 
| 


return(FALSE); 


/* the following routine tests the first 4 bytes of the sender 
segment to see if they are non-zero. 
it uses an input structure since called by main program 


*/ 
int sender_is_free(instructure) 
Machine *instructure; /* includes 


char *instructure.segment a pointer to the shared segment */ 


if(*((long *)instructure->segment + WSENDEROFFSET) == 0) 
{ 


return(TRUE); 
) 


else 


| 


return(FALSE) ; 
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/* the following routine reads on the input socket into the receiver segment. */ 


read_socket_into_segment(socket,segment) 


int 


socket: /* a socket descriptor */ 


char *segment; /* a ptr to the shared segment */ 


| 


long nbytes; /* the number of bytes read in */ 


char temp[ LARGESTREAD] ; 


/* read the data into a temporary array to avoid segment protection 
violation since the socket does not share witl the shared memory 


segment. 
5, 
nbytes — read(socket , temp, LARGESTREAD) ; 


if(nbytes <= 0) 
| 


/* the following routine calls are commented out for the following 
reason: 


nbytes <= 0 means that the socket has been broken. 


This routine is called by the receiver process so the only 
intelligent thing to do is to terminate the receiver process, 
ee cal lexi ta. 


perror("read"); 
printf("READ SOCKET _INTO_SEGMENT: number of bytes read = %d\n" ,nbytes) ; 
ny 
shutdown( socket, 2 ); 
close( socket ); 
expe): 


/* copy the data into the shared segment */ 
memcpy((segment + RECEIVEROFFSET + 4),temp,nbytes); 


/* set the number of bytes in the shared segment */ 
*((long *)segment + WRECEIVEROFFSET) = nbytes; 
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/* the following routine writes the data from the sender side 
of the shared segment to the socket */ 


write_socket_from_segment(socket,segment) 


int socket; /* socket descriptor */ 
char *segment ; /* pointer to the shared segment */ 
| 

long nbytes; /* the number of bytes to write */ 


char temp[LARGESTREAD] ; 


/* copy the data into a temporary array to avoid segment protection 
violation since the socket does not share with the shared memory 
segment. 


e] 
memcpy(temp,( (char *)segment + SENDEROFFSET + 4), 
*((long *)segment + WSENDEROFFSET)); 


/* write the data to the socket */ 


nbytes = write(socket,temp, *((long *)segment + WSENDEROFESET) ); 


if(nbytes <= 0 ll nbytes != *((long *)segment + WSENDEROFFSET) ) 
| 


jt 


This error indicates the socket is broken. Just exit the 
sender process. 


perror("write"); 

printf("WRITE_SOCKET_FROM_SEGMENT: number of bytes written = %d\n" ,nbytes); 
printf( "Number of bytes in shared segment = %d\n",*(( long *)segment + WSENDEROFFS 
v 


shutdown( socket, 2 ); 
close( socket ); 
exit(1); 


| 


/* free the sender segment */ 
free lsender( segment): 
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/* The following routine receives on the input datagram socket. 
If the message matches the mname and portnum it is copied into the 
receiver area of the shared memory segment. 
O is returned if the message does not match mname and portnum, 
the number of bytes read is returned if it does match. */ 
int broadcast_into_segment(socket,segment ,mname, portnum) 
int socket; /* a socket descriptor */ 
char *segment; /* a ptr to the shared segment */ 
char mname[]; /* machine name of broadcaster */ 
long portnum; /* port number of broadcaster */ 
| 
long nbytes; /* the number of bytes read in */ 
char temp[LARGESTREAD]; 
int flags = 0; /* flags = O indicates none set */ 
struct sockaddr_in who; /* Internet structure for message sender address */ 


int wholen; /* length of received address struct who */ 


struct hostent *broadcaster; /* pointer to structure with info on 
broadcaster */ 


static long broadcast_address; /* address of broadcaster */ 
static short broadcast_port; /* port of broadcaster */ 


static Boolean firsttime = TRUE; 


/* read the data into a.temporary array to avoid segment protection 
violation since the socket does not share with the shared memory 
segment. This also allows checking for match with desired broadcaster. 

E 

nbytes = recvfrom( socket, temp, LARGESTREAD, flags, 

(struct sockaddr *)&who, &wholen ); 


1f(nbytes <= 0) 
{ 
perrom( reevirom: ); 


else 


if( firsttime ) 


/* determine desired broadcaster address and port */ 


broadcast_port htons((short)portnum); 
broadcaster = (struct hostent *)gethostbyname( mname ); 


bcopy( broadcaster->h_addr, (char *)&broadcast_address, 
broadcaster->h_length ); 


if( (broadcast address 
(broadcast port 
( 


who.sin addr.s addr) && 
who.sin, port) ) 
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/* copy the data into the shared segment */ 
memcpy((segment + RECEIVEROFESET + 4),temp,nbytes); 


/* set the number of bytes in the shared segment */ 
*((long *)segment + WRECEIVEROFFSET) = nbytes; 


else 


| 
nbytes = 0; 
/* Set nbytes to 0 so return of function indicates no match */ 


return( nbytes ); 
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/* the following routine sends the data from the sender side 
of the shared segment to the socket for broadcast */ 


send_socket_from_segment(socket,portnum,segment) 


int socket; /* socket descriptor */ 
long portnum; /* port number of broadcaster */ 
char *segment; /* pointer to the shared segment */ 
| 

long nbytes; /* the number of bytes to write */ 


char temp[ LARGESTREAD] ; 
short broadcaster port; 
static Boolean firsttime = TRUE; 


static struct sockaddr in network - ( AF INET ]); /* structure for broadcast 
address */ 


if( firsttime ) 

| 
broadcaster port - IPPORT RESERVED + portnum; 
/* Set up broadcasting address structure */ 
network.sin family AF INET:; 
network.sin addr.s addr htonl ( INADDR BROADCAST) ; 
network.sin port htons(broadcaster port); 


firsttime FALSE; 


| 


/* copy the data into a temporary array to avoid segment protection 
violation since the socket does not share with the shared memory 
segment. 

ni 

memcpy(temp,((char *)segment + SENDEROFESET + 4), 

*((long *)segment + WSENDEROFFSET) ) ; 


/* broadcast the data through the socket */ 
nbytes = sendto( socket, temp, *((long *)segment + WSENDEROFESET), 0, 
(struct sockaddr *)&network, sizeof(network) ); 


if(nbytes <= 0 Il nbytes != *((long *)segment + WSENDEROFFSET) ) 
| 
pe 


This error indicates the socket is broken. Just exit the 
sender process. 


S 


perror( write’): 

printf("WRITE_SOCKET_FROM_SEGMENT: number of bytes written = %d\n",nbytes); 

printf( "Number of bytes in shared segment = %d\n",*(( long *)segment + WSENDEROFFSET 
shutdown( socket, 2 ); 

close( socket ); 

exit(l); 


[* free the sender segment */ 
free sender(segment); 
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/* the following routine deletes the sender by writing 
a megative byte count into the shared segment 
and then waking up the sender. 


DI 

kill_sender(segment,sendsem) 

char *segment; /* ptr to thes sepPmenra 

int sendsem; /* semaphore to the sender */ 


| 


/* write a negative number into the byte count field. */ 


*(( long *)segment + WSENDEROFFSET) = -1; 


/* at this point, we should send a wakeup to the sender program. 
the sender will read the bad byte count and exit. 
ui 


V(sendsem); 


/* the following routine deletes the receiver by writing 
a negative byte count into the shared segment 
and then waking up the receiver. 


t 
kill receiver(segment,receivesem) 
char *segment; /* ptr to thessepmenmto^7 


int receivesem; /* semaphore to the receiver */ 


| 


/* we do not wait until the receiver segment is free here 
as the process that calls this routine should already 
have read the last piece of data. 

my, 

/* write a negative number into the byte count field. */ 


*((long *)segment + WRECEIVEROFESET) = -1; 


/* at this point, we should send a wakeup to the receiver program. 
the receiver will read the bad byte count and exit. 
7 


V(receivesem); 
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APPENDIX B - TI EXPLORER MODULE DESCRIPTIONS 


All functions, methods, and flavor are contained in file irisflavor.lisp. 


1. Calling Protocols 

The module contains functions, methods, and a flavor that are intended for the 
application's use. It also contains a macro and functions that are used internally. The 
parameters for externally accessible functions and methods are described below. 


a. iris 
(defun iris (x) where x is number of iris machine desired 
b.  start-iris 


(defmethod (conversation-with-iris :start-iris) 


() 
c.  get-iris 
(defmethod (conversation-with-iris :get-iris) 
() 
d.  put-iris 
(defmethod (conversation-with-iris :put-iris) 
(object) 


(let* ((buffer (cond 
((equal (type-of object) 'bignum) (convert-number-to-string object)) 
((equal (type-of object) 'fixnum) (convert-number-to-string object)) 
((equal (type-of object) 'float) (convert-number-to-string object)) 
((equal (type-of object) 'string) object) 
(t error ) )) 


e.  Stop-iris 


(defmethod (conversation-with-iris :stop-iris) 


() 
f. reuse-iris 


(defmethod (conversation-with-iris :reuse-iris) 
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2. Code and Description 


(defmacro loopfor (var init test expl &optional exp2 expJ exp4 exp5) 
"(prog () 
(setg var init) 
tag 
expl 
Exp 
"exp 
,exp4 
expo 
(setq ,var (l+ ,var)) 
(if (= var test) (Fotura colo ta a) e) 


(defun convert-number-to-string (n) 
(princ-to-string n) ) 


(defun convert-string-to-integer (str &optional (radix 10)) 
(do ((j 0 (+ j 1)) 
(n O (+ (* n radix) (digit-char-p (char str j) radix))) ) 
((= j (length str)) n) ) ) 


(defun find-period-index (str) 
(catch ‘exit 
(dotimes (x (length str) nil) 
(if (equal (char str x) (char "." 0)) 
(throw ‘exit x) ) ) ) ) 


(defun get-leftside-of-real (str &optional (radix 10)) 
(do CC OEE) 
(n O (+ (* n radix) (digit-char-p (char str j) radix))) ) 
((or (null (digit-char-p (char str j) radix)) (= j (length str))) n) ) ) 


(defun get-rightside-of-real (str &optional (radix 10)) 
(do ((index (1+ (find-period-index str)) (1+ index)) 
(factor 0.10 (* factor 0.10)) 
(n 0.0 (+ n (* factor (digit-char-p (char str index) radix)))) ) 
((= index (length str)) n) ) ) 


(defun convert-string-to-real (str &optional (radix 10)) 
(+ (float (get-leftside-of-real str radix)) (get-rightside-of-real str radix)) ) 


(defvar *tcp-handlerl* (send ip::*tcp-handler* :get-port)) 
(defvar *tcp-handler2* (send ip::*tcp-handler* :get-port)) 


(defvar *irisl-portl* 1027) ; this is the send port 
(defvar *irisl-port2* 1026) >; this r3 the receive port 


(defvar *irisl-address* 3221866502) 
(defvar *iris2-address* 3221866504) 
(defvar *iris3-address* 3221866505) 


(defvar *dest-address* nil) ; the tcp-ip or internet address 
look in network configuration 


(defun iris (x) 
(cond ((equal x 1) (setq *dest-address* *irisl-address*)) 
((equal x 3) (setq *dest-address* *iris3-address*)) 
( 


(t setq *dest-address* *iris2-address*)) ) ) 
(defflavor conversation-with-iris ((talking-port-number O) 
(listening-port-number  *irisl-port2*) 
(talking-port *tcp-handlerl*) 
(listening-port *tcp-handler2*) 
(destination *dest-address*) ) 
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() 


:gettable-instance-variables 
:settable-instance-variables 
:initable-instance-variables ) 


(defmethod (conversation-with-iris :start- iris) 
() 
(progn 
(send talking-port :open 
active ; tep will begin the procedure to establish 
connection (default vs :passive) 
port number of destination host 
machine name or address if blank and 
in :passive mode local machine waits for 
connection 


talking-port-number 
destination 


è è ot ot .. 40° we 


30 ) set max seconds before read request times out 
(send listening-port :open 
:active ;:passive 


listening-port-number 
destination 
30 ) 
'"A conversation with the iris machine has been established" ) ) 


(defmethod (conversation-with-iris :reuse-iris) 
() 

(setq *tcp-handlerl* (send ip::*tcp-liandler* :get-port) 
*tcp-handler2* (send ip::*tcp-handler* :get-port) 
talking-port *tcp-handlerl* 
listening-port *tcp-handler2* ) ) 


(de fmethod (conversation-with-iris :get-iris) 


() 
(let* ((typebuffer S) 
(lengthbuffer " m) 
(buffer ZEN 
(buffer-length 1) ) 
| (progn 
(send listening-port :receive 
typebuffer 
buf fer-length 
30 
‘walt ) 
(send listening-port :receive 
lengthbuffer 
4 
30 
¿wait ) 


(setq buffer-length (convert-string-to-integer lengtlibuffer)) 
(setq buffer (make-string buffer-length :initial-element (character 32))) 
(send listening-port :receive 


buffer 
buffer-length 
30 
¡wait ) 
(cond ((equal typebuffer "I") (convert-string-to-integer buffer)) 
((equal typebuffer "R") (convert-striug-to-real buffer)) 


((equal typebuffer "C") buffer) 
(t nil) ) ) ) ) 


(de fmetliod (conversation-with-iris :put-iris) 
(object) 
(let* ((buffer (cond 
((equal (type-of object) 'bignum) (convert-number-to-string object)) 
((equal (type-of object) 'fixnum) (convert-nuniber-to-string object)) 

((equal (type-of object) 'float) (convert-nunber-to-string object)) 
((equal (type-of object) 'string) object) 

(t "error") )) 

(buffer-length (length buffer)) 
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(typebuffer (cond ((equal (type-of object) 'bignum) "I") 
((equal (type-of object) 'fixnum) "I") 
((equal (type-of object) 'float) "R") 
(Cequal (type-of object) strrmme, = ©) 
(t GN »» 
(lengthbuffer (convert-number-to-string buffer-length)) 
(*loopvariable* 0) ) 
(progn 
(send talking-port :send 
typebuffer 
1 


nil 
nue 
(1f (= (length lengthbuffer) 4) 
(send talking-port :send 
lengthbuffer 
4 


nil 
nil ) 
(progn 
(loopfor *loopvariable* (length lengthbuffer) 4 
(send talking-port :send "0" 1 nil nil) ) 
(send talking-port :send lengthbuffer (length lengthbuffer) nil nil) ) ) 
(send talking-port :send 


buffer 
buffer-length 
t 

nil ) ) ) ) 


(de fmethod (conversation-with-iris :stop-iris) 


() 
(progn (send talking-port :close) (send listening-port :close)) ) 
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APPENDIX C - SYMBOLICS MODULE DESCRIPTIONS 


All functions, methods, and flavor are contained in file irisflavor.lisp. 


l. Calling Protocols 

The module contains functions, methods, and a flavor that are intended for the 
ME ons use. It also contains a macro and functions that are used internally. The 
parameters for externally accessible functions and methods are described below. 


a.  select-host 
(defun select-host (host-name) 
b.  start-iris 


(defmethod (:start-iris conversation-with-iris) 


() 
c. get-iris 
(de fmethod (:get-iris conversation-with-iris) 
() 
d.  put-iris 
(defmethod (:put-iris conversation-with-iris) 
(object) 


(let* ((buffer (cond 
((equal (type-of object) ’bignum) (convert-number-to-string object)) 
((equal (type-of object) 'fixnum) (convert-number-to-string object)) 
((equal (type-of object) 'single-float) (convert-number-to-string object)) 
((equal (type-of object) 'string) object) 
(t error") )) 


e. stop-iris 


(defmethod (:stop-iris conversation-with-iris) 


f. reuse-iris 


(defmethod (:reuse-iris conversation-with-iris) 
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2. Code and Description 
::; -*- Mode: LISP; Syntax: Common-lisp; Package: USER -*- 
handy macro to have in the send message farthur down 


(defmacro loopfor (var init test expl &optional exp2 exp3 exp4 exp5) 
pros () 

(setg „var ,„init) 

tag 
, expl 
Xp? 
Rep 
, exp4 
,exps 
(setq ,var (l+ ,var)) 
(if (= ,var ,test) (return t) (go tag)) ) ) 


(defun convert-number-to-string (n) 
(princ-to-string n) ) 


(defun convert-string-to-integer (str &optional (radix 10)) 
(do ((j 0 (+ j 1)) 
(n O (+ (* n radix) (digit-char-p (char str j) radix))) ) 
((= j (length str)) n) ) ) 


(defun find-period-index (str) 
(catch ‘exit 
(dotimes (x (length str) nil) 
(if (equal (char str x) (char =. 0)) 
(throw 'exit x) ) ) ) ) 


(defun get-leftside-of-real (str &optional (radix 10)) 
(do ((j O (1+ j)) 
(n O (+ (* n radix) (digit-char-p (char str j) radix))) ) 
((or (null (digit-char-p (char str j) radix)) (= j (length str))) n) ) ) 


(defun get-rightside-of-real (str &optional (radix 10)) 
(do ((index (1+ (find-period-index str)) (1+ index)) 
(factor 0.10 (* factor 0.10)) 
(n 0.0 (+ n (* factor (digit-char-p (char str index) radix)))) ) 
((= index (length str)) n) ) ) 


(defun convert-string-to-real (str &optional (radix 10)) 
(+ (float (get-leftside-of-real str radix)) (get-rightside-of-real str radix)) ) 


(defvar “iris-portl< 1027) ; this is the send port 

(defvar *iris-port2* 1026) this is the receive port 
(defvar *local-talk-port* 1500) this is the local send port 
(defvar *local-listen-port* 1501) this is the local receive port 


wee we wee 


(defflavor conversation-with-iris ((talking-port-number *iris-portl*) 
(listening-port-number ES Por tz") 
(local-talk-port-number *local-talk-port*) 


(local-listen-port-number *local-listen-port*) 
(talking-stream) 
(listening-stream) 
(destination-host-object) ) 


() 


:initable-instance-variables ) 
(de fmetliod (:init-destination-liost conversation-with-iris) 


(name -of-host) 
(setf destination-host-object (net:parse-host name-of-host)) ) 
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(defmethod (:start-iris conversation-with-iris) 
() 
(setf talking-stream 
(tcp:open-tcp-stream destination-host-object 
talkiug-port-number 
local-talk-port-number ) ) 
(setf listening-stream ; 
(tcp:open-tcp-stream destination-host-object 
listening-port-number 
local-listen-port-number ) ) 
"A conversation with the iris machine has been established” ) 


(defmethod (:reuse-iris conversation-with-iris) 
() 
) 


(defun read-string (stream num-chars) 
(let ((out-string "")) 
(dotimes (i num-chars) 
(setf out-string (string-append out-string (read-char stream))) ) 
out-string ) ) 


(defmethod (:get-iris conversation-with-iris) 


( ) 
(lert ((typeb burr er NUES 


(lengthbuffer " ") 
(buffer P) 
(buffer-length 1) ) 
(progn 


(setf typebuffer 
(read-string listening-stream 1) ) 
(setf lengthbuffer 
(read-string listening-stream 4) ) 
(setf buffer-length 
(convert-string-to-integer lengthbuffer) ) 
(setf buffer 
(read-string listening-stream buffer-length) ) 


(cond ((equal typebuffer "I") (convert-string-to-integer buffer)) 
((equal typebuffer "R") (convert-string-to-real buffer)) 
((equal typebuffer "C") buffer) 

(t nil) ) ) ) ) 


(eiva step-var* 0) 


(defun my-write-string(string stream) 
(let* ((num-chars (length string))) 
(dotimes (1 num-chars) 
(write-char (aref string 1) stream) ) ) ) 


(defmethod (:put-iris conversation-with-iris) 
(object) 
(let* ((buffer (cond 
((equal (type-of object) 'bignum) (convert-number-to-string object)) 
((equal (type-of object) 'fixnum) (convert-number-to-string object)) 
((equal (type-of object) 'single-float) (convert-number-to-string object)) 
((equal (type-of object) 'string) object) 
(t "errors ) 


(buffer-length (length buffer)) 

(typebuffer (cond ((equal (type-of object) ’bignum) "I") 
((equal (type-of object) 'fixnum) "I") 
((equal (type-of object) 'single-float) "R") 
((equal (type-of object) 'string) "C") 
(t CS) )) 


(lengthbuffer (convert-number-to-string buffer-length)) ) 
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(progn 


(my -write-string typebuffer talking-stream) 
(send talking-stream :force-output) 
(if (= (length lengthbuffer) 4) 


(write-string lengthbuffer talking-stream) 
(progn 


(loopfor *step-var* (length lengthbuffer) 4 
(write-string "0" talking-stream) ) 


(my -write-string lengthbuffer talking-stream) ) ) 
(send talking-stream :force-output) 
(my -write-string buffer talking-stream) 


(send talking-stream :force-output) ) ) ) 
(defmethod (:stop-iris conversation-with-iris) 
() 


(progn (send talking-stream :close) 
(send listening-stream :close) ) ) 


(defun select-host (host-name) 
(send talk 


:init-destination-host host-name) ) 
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APPENDIX A - TEST AND UTILITY PROGRAMS 


l. gprog.c 
a. Calling Protocols 


This is a test program for the direct connect protocol. By command line 
argument, another machine to receive direct connect messages from can be specified. 
The default is to receive messages from iris2. It must be run in conjunction with 
gprog2.c to function properly, as the port assignments are hardcoded. Since it is the 


server program, 1t must be started before gprog2.c. 


b. Code and Description 
Poewthis is file -cpros.c 


It is a sample top level program for the asynchronous reading 
and writing of sockets via shared memory and two other processes. 


This program spawns off the required processes. 
This program uses structure type Machine declared in file shared.h. 
This is the SERVER side program and runs first!!!. 

x 

include "shared.h" 


#include "gl.h" 
#include "device.h" 


main(argc,argv) 


int argc; /* argument count */ 
char *argv[]; /* pointers to the passed in arguments */ 
{ 
Machine remotemachine; /* structure for remote machine */ 
char other_machine[50]; /* name of other machine */ 
char mybuf fer[ LARGESTREAD] ; /* received data */ 
char outgoing[LARGESTREAD]; /* outgoing message's buffer */ 


int mybufferl[LARGESTREAD/ INTEGER SIZE]; /* received integer data */ 

int outgoingl [LARGESTREAD/ INTEGER SIZE]; /* outgoing integer message's buffer */ 
float mybuffer2[LARGESTREAD/FLOAT SIZE]: /* received float data */ 

float outgoing2[LARGESTREAD/FLOAT SIZE]: /* outgoing float message buffer */ 


long noutgoing; /* size of the outgoing message */ 
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char temp[10]; /* temp array used to make outgoing message */ 
long count = 0; /* message counter */ 
char received type(); 
char type received; 
int elements received; 
long i; /* temp loop variable */ 


long j 2 0; /* variable to control message sending */ 


/* pull out the string from the argument list */ 

if(argc > 2) 

| 
printf("GPROG: incorrect argument count! use gprog <alias>\n"); 
exit(1); 


/* pull out the name of the other string, if it exists */ 
if( argc == 2 ) 
| 
strcpy( other machine, "npscs-" ); 
strcat( other machine, argv[1] ); 
} 
else 
strcpy( other machine, "npscs-irisl" ); 


/* create a path to a particular machine (irisl default) */ 
/* the first argument is the key for the shared memory segment. 
the second argument is the name of the machine to connect to. 
the third argument is the sending port number for the socket to use. 
the fourth argument is the receiving port number for the socket to use. 
the fifth argument indicates whether the processes should 
act as a server or a client. 
the sixth argument is the returned pointer to the structure 
remot emachine. 
it includes the pointer to the shared memory segment, 
the system generated shared memory id, the sendsem id, 
and the returned receivesem id. 
the seventh argument is the amount of freespace desired for dynamic 
memory allocation during execution of the program. 
m 


dynamicmachinepath(1,other machine,1,2, "server" ,&remotemachine,2000000) ; 


/* the loop for polling the shared segment */ 
while(TRUE) 
| 


/* make an outgoing message */ 
strcpy(outgoing, "GPROG ORIGINATED MESSAGE: "); 
count = count - 1; 

outgoingl[0] = count; 

noutgoing = strlen(outgoing); 

outgoing2[0] = count; 

/* is there data in the shared segment? */ 


if(receiver has data(&remotemachine)) 


| 


type, received - received type(&remotemachine); 
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printf("The message received by GPROG is of type %c \n", 
type recerved): 


switch (type_received) 


case CHARACTER_ARRAY_TYPE: 


elements_received = number_received(&remotemachine); 


printf("The message received by GPROG is %d elements long!\n", 
elements_received); 


read characters(&remotemachine, mybuffer, elements, received); 
break; 


case INTEGER, TYPE: 


read integer(&remotemachine ,mybufferl); 
break; 


case FLOAT TYPE: 
read float(&remotemachine,mybuffer2); 


break: 
) 


/* at this point in the program, process the received data...*/ 
printf("GPROG has received the following data:\n"); 


switch (type_received) 


{ 
case CHARACTER_ARRAY_TYPE: 


for(i=0; i < elements_received; i+=l1) 


{ 
printf("%c" mybuffer[i])); 


break; 


case INTEGER_TYPE: 
printf£("%d" mybuffer1(0]); 
break; 


case FLOAT_TYPE: 
printf("%f" mybuffer2[0]); 
break; 


) 
printf("\n"); 
) 


/* at this point, we would look at our system and see ¡f we needed 
to send data. Instead, I will check if the sender is free. 
If the sender is free, I will send one of three messages */ 


if(sender 1s free(&remotemachine)) 


if((j % 3) == 0) 
write characters(&remotemachine,outgoing,noutgoing); 


/* wait until message sent before attempting to send another */ 
while( !sender is free(&remotemachine) ) /* do nothing */ 


if((j % 3) == 1) 
write integer(&remotemachine,outgoingl); 


/* wait until message sent before attempting to send another */ 
while( !sender, is free(&remotemachine) ) /* do nothing */ 


if((j % 3) == 2) 


write float(&remotemachine,outgoing2); 
++]; 


else 
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/* assume socket connection broken */ 
printf("Sender wasn't free! Terminat ting... \n ); 
break; 


} /* endif while TRUE */ 


/* get rid of the path to the other machine...*/ 
deletemachinepath(&remotemachine); 
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2. gprog2.c 


a. Calling Protocols 
This is a test program for the direct connect protocol. By command line 
argument, another machine to receive direct connect messages from can be specified. 
The default is to receive messages from iris/. It must be run in conjunction with 
gprog.c to function properly, as the port assignments are hardcoded. Since it is the 


client program, it be started after gprog.c is ready for it. 


b. Code and Description 
Veethis is file jgprog2.c 


It is a sample top level graphics program for the asynchronous reading 
and writing of sockets via shared memory and two other processes. 


This program spawns off the required processes. 
This program uses structure type Machine declared in file shared.h. 
This is the CLIENT side program and runs second!!!. 

2 

#include "shared.h" 


#define TRUE 1 


main(argc,argv) 


int argc; /* argument count */ 
char *argv[]; /* pointers to the passed in arguments */ 
( 
Machine remotemachine; /* structure for remote machine */ 
char other machine[50]; /* name of other machine */ 
char mybuf fer [LARGESTREAD] ; /* received data */ 
char out going [LARGESTREAD] ; /* outgoing message’s buffer */ 


int mybuf fer 1[LARGESTREAD/ INTEGER SIZE]; /* received integer data */ 

int outgoingl1[LARGESTREAD/ INTEGER SIZE]: /* outgoing integer message's buffer */ 
float mybuffer2[LARGESTREAD/FLOAT SIZE]; /* received float data */ 

float outgoing2[LARGESTREAD/FLOAT SIZE]: /* outgoing float message buffer */ 


long noutgoing; /* size of the outgoing message */ 
char temp[10]; /* temp array used to make outgoing message */ 
long count = 0: /* message counter */ 


char received typel(): 
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char type received; 
int elements received; 
long i: /* temp loop variable */ 


long j = 0; /* variable to control message sending */ 


/* pull out the string from the argument list */ 

1i (arge eon 2) 

| 
printf("GPROG2: incorrect argument count! use gprog2 <alias>\n"); 
exit(1); 


/* pull out the name of the other string, if it exists */ 
if( arge == 2 ) 
| 
strcpy( other machine, "npscs-" ); 
strcat( other machine, argv[1] ); 
) 
else 
strcpy( other machine, "npscs-iris2" ); 


/* create a path to a particular machine (iris2 default) */ 
/* the first argument is the key for the shared memory segment. 
the second argument is the name of the machine to connect to. 
the third argunent is the sending port number for the socket to use. 
the fourth argument is the receiving port number for the socket to use. 
the fifth argument indicates whether the processes should 
act as a server or a client. 
the sixth argument is the returned pointer to the structure 
remotemachine. 
it includes the pointer to the shared memory segment, 
the system generated shared memory id, the sendsem id, 
and the returned receivesem id. 
2 


machinepath(l,other_machine,2,1,"client” ,&remotemachine) ; 


/* the display loop and loop for polling the shared segment */ 
whi | e ( TRUE) 


/* make an outgoing message */ 
strcpy(outgoing, "IRISI ORIGINATED MESSAGE: "); 


count = count + 1; 

outgoingl[0] = count; 

noutgoing = strlen(outgoing); 

outgoing2[0] = count; 

/* is there data in the shared segment? */ 
y O all 


type received - received type(&remotenmachine); 


printf("The message received by IRISI is of type %c \n", 
type lrecemved).. 


switch (type_received) 


{ 
case CHARACTER ARRAY TYPE: 


elements received - number received(&remotemachine); 
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printf("The message received by IRISI is %d elements long!\n", 
elements received); 


read characters(&remotemachine ,mybuffer, 
elements Tecernved). 
break; 


case INTEGER_TYPE: 
read integer(&remotemachine,mybufferl); 
break; 


case FLOAT TYPE: 
read float(&remotemachine,mybuffer2); 
break; 


/* at this point in the program, process the received data...*/ 
printf("IRIS1 has received the following data:\n"); 


switch (type_received) 


case CHARACTER ARRAY TYPE: 


for(iz0; i « elements received; i+=1) 


printf("%c",mybuffer[i]); 


break: 


case INTEGER_TYPE: 
printf("%d" mybuffer1[0]); 
break; 


case FLOAT_TYPE: 
printf("%f” mybuffer2[0]); 
break; 
) 


/* at this point, we would look at our system and see if we needed 
to send data. Instead, I will check if the sender is free. 
If the sender is free, I will send one of three messages */ 
if(sender_is_free(&remotemachine)) 


printf("\n"); 


í 
if((j % 3) == 0) 
write characters(&remotemachine,outgoing,noutgoing); 


/* wait until message sent before attempting to send another */ 
while( !sender is free(&remotemachine) ) /* do nothing */ printf("2"):; 


if((j % 3) == 1) 
write_integer(&remotemachine,outgoingl); 


/* wait until message sent before attempting to send another */ 
while( !sender is free(&remotemachine) ) /* do nothing */ printf("3"): 


MA == 02) 
write float(&renmotemachine,outgoing2):; 


ttj; 


else 
/* assume socket connection broken */ 


printf("Sender wasn't free! Terminating...\n"); 
break: 
| 
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/* at this point, you can do the rest of the display loop */ 
} /* endif while TRUE */ 


/* get rid of the path to the other omuchince.. 
deletemachinepath(&remotemachine): 
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a. Calling Protocols 
This 1s a test program for the broadcast protocol. By command line argument, 
another machine to receive broadcast messages from can be specified. The default is to 
receive messages from iris2. It must be run in conjunction with prog2.c to function 


properly, as the port assignments are hardcoded. 


b. Code and Description 


this is file preg.c 


It is a sample top level program for the asynchronous reading 
and writing of sockets via shared memory and two other processes. 


This program spawns off the required processes. 

This program uses structure type Machine declared in file shared.h. 
a 
#include "shared.h" 
#define TRUE 1 


main(argc,argv) 


int argc; /* argument count */ 

char *argv[]; /* pointers to the passed in arguments */ 

| b e 
Machine remotemachinel; /* first structure for remote machine */ 
Machine remotemachine2; /* second structure for remote machine */ 

ul 

char other _machine[50]; /* name of other machine */ 
char mybuf fer (LARGESTREAD| ; /* received data */ 
char outgoing[LARGESTREAD] ; /* outgoing message's buffer */ 


int mybuf fer 1[LARGESTREAD/ INTEGER SIZE]; /* received integer data */ 

int outgoingl[LARGESTREAD/ INTEGER SIZE]; /* outgoing integer message's buffer */ 
float mybuf fer2(LARGESTREAD/FLOAT SIZE]; /* received float data */ 

float outgoing2[(LARGESTREAD/FLOAT SIZE]: /* outgoing float message buffer */ 


long noutgoing; /* size of the outgoing message */ 
char temp[10]; /* temp array used to make outgoing message */ 
long count = 0: /* message counter */ 


char received_type(): 


char type received; 
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int elements received; 
long i: [|* temp loop variable */ 


long j = 0; /* variable to control message sending */ 


/* pull out the string from the argument list */ 

large a A) 

| 
printf("PROG: incorrect argument count! use prog <alias>\n"); 
Sxl): 


/* pull out the name of the other string, if it exists */ 
if( argc == 2 ) 
| 


strepy( other_machine, argv{l] ); 


eae 
strcpy( other machine, "npscs-iris2" ); 


/* create a pair of paths to a particular machine (iris2 default) */ 
/* the first argument is the maximum number of channels to be created. 
the second argument is the key for the shared memory segment. 
the third argument is the name of the machine to connect to. 
the fourth argument is the sending port number for the socket to use. 
the fifth argument is the receiving port number for the socket to use. 
the sixth argument indicates whether the processes should 
act as a receiver or a broadcaster. 
the seventh argument is the returned pointer to the structure 
remotemachinel or remotemachine2. 
it includes the pointer to the shared memory segment, 
the system generated shared memory id, the sendsem id, 
and the returned receivesem id. 
D 


dynamicmachinepaths(2,1,other_machine,2,1,"receive” ,&remotemachinel); 
sleep(5); /* to let both sides set up receiving channels first */ 


dynamicmachinepaths(2,l,other_machine,4,3,"broadcast",&remotemachine2); 


/* the loop for polling the shared segment limited to avoid send buffer 
overflow */ 

while (TRUE) 

| 
/* make an outgoing message */ 


strcpy(outgoing, "PROG ORIGINATED MESSAGE: "); 


count = count + 1; 
outgoingli[0] = count; 
noutgoing = strlen(outgoing); 


outgoing2[0] = count; 





/* is there data in the shared segment? */ 
if(receiver has data(&remotemachinel)) 


| 


type received - received type(&remotemachinel); | 


printf("The message received by PROG is of type %c \n". 
type_received); 


switch (type_received) 
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case CHARACTER_ARRAY_TYPE: 


elements _ received = number_received(&remotemachinel): 


print Mie message received by PROG is %d elements long!\n". 
elements received). 


read characters(&remotemachinel,mybuffer, 
elements received): 
break: 


case INTEGER TYPE: 
read integer(&remotemachinel ,mybufferl); 
break; 


case FLOAT TYPE: 
read float(&remotemachinel ,mybuffer2); 
break: 


AUP me point in the program, process thé received data...*/ 
printf( "PROG has received the following data:\n"); 


switch (type_received) 
| 
case CHARACTER ARRAY TYPE: 
for(i=0:; i < elements received; i--1) 


| 


} 
break: 


case INTEGER_TYPE: 
printf("%d",mybufferl[0]); 
break; 


case FLOAT_TYPE: 
printf("%f",mybuffer2[0]); 
break; 


pups mvbufFrepgi]- 


/* at this point, we would look at our system and see if we needed 
to send data. Instead, I will check if the sender is free. 
If the sender we free, I will send one of three messages */ 
if(sender_is_free(&remotemachine2)) 


pri been): 


| 
if((j % 3) == 0) 


write characters(&remotemachine2,outgoing,noutgoing); 


/* wait until message sent before attempting to send another */ 
apre sender 1s free(&remotemachine2) ) /* do nothing printf("2")*/ 


Pieces) == 1) 
write integer(&remotemachine2,outgoingl); 


/* wait until message sent before attempting to send another */ 
mnes sendercis-ctree(c&remotemachine2) ) 7* do nothing printf("3")*/ 


Vien ces) == 2) 
write float(&remotemachine2,outgoing2):; 


/* wait until message sent before continuing */ 
while( !sender is free(&remotemachine2) ) /* do nothing printf("4")*/ 


++]; 


} 


else 
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{ 
/* assume socket connection broken */ 
printf(" Sendern wasni t frocelòon i. 
break: 
) 


/* at this point, you can do the rest of the display loop */ 
} /* endif while TRUE */ 
[* get rid of the path to the other machune. .. 7 


deletemachinepath(&remotemachinel); 
deletemachinepath(&remotemachine2); 
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4. prog2.c 


a. Calling Protocols 
This 1s a test program for the broadcast protocol. By command line argument, 
another machine to receive broadcast messages from can be specified. The default is to 
receive messages from iris]. It must be run in conjunction with prog.c to function 


properly, as the port assignments are hardcoded. 


b. Code and Description 
e this is file prog2.c 


It is a sample top level program for the asynchronous reading 
and writiug of sockets via shared memory aud two other processes. 


This program spawns off the required processes. 

This program uses structure type Machine declared in file shared.h. 
=) 
#include "shared.h" 
#define TRUE 1 


main(argc,argv) 


int argc; /* argument count */ 

char *argv[]; /* pointers to the passed in arguments */ 

| L] . . . 
Machine remotemachinel; /* first structure for remote machine */ 
Machine remotemachine2; /* second structure for remote machine */ 
char other machine[50]; /* name of other machine */ 
char mybuf fer [LARGESTREAD] ; /* received data */ 
char outgoing[LARGESTREAD] ; /* outgoing message's buffer */ 


int mybuf fer1 [LARGESTREAD/ INTEGER SIZE]; /* received integer data */ 

int outgoingl[LARGESTREAD/ INTEGER SIZE]; /* outgoing integer message's buffer */ 
float mybuffer2[LARGESTREAD/FLOAT SIZE]; /* received float data */ 

float outgoing2[LARGESTREAD/FLOAT SIZE]; /* outgoing float message buffer */ 


long noutgoing; /* size of the outgoing message */ 
char temp[10]; /* temp array used to make outgoing message */ 
long count = 0; /* message counter */ 


char received_type(); 


char type_received; 
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int elements_received; 
long i; /* temp loop variable */ 


long j = 0; /* variable to control message sending */ 


/* pull out the string from the argument list */ 

if(argc > 2) 

| 
printf("PROG2: incorrect argument count! use gprog2 <alias>\n"); 
exit(1); 


/* pull out the name of the other string, if it exists */ 
if( argc == 2 ) 
| 


strcpy( other machine, argv[1] ); 


else 
strcpy( other, machine, "npscs-iris2" ); 


/* create a path to a particular machine (iris2 default) */ 
/* the first argument is the maximum number of channels to be created. 
the second argument is the key for the shared memory segment. 
the third argument is the name of the machine to connect to. 
the fourth argument is the sending port number for the socket to use. 
the fifth argument is the receiving port number for the socket to use. 
the sixth argument indicates whether the processes should 
act as a server or a client. 
the seventh argument is the returned pointer to the structure 
remotemachinel or remotemachine2. 
it includes the pointer to the shared memory segment, 
the system generated shared memory id, the sendsem id, 
and the returned receivesem id. 
y 


dynamicmachinepaths(2,1,other machine,3,4, "receive" ,&remotemachine2); 
sleep(5); /* to let both ends of the process get set up */ 
dynamicmachinepaths(2,1,other, machine,1,2,"broadcast" ,&remotemachinel); 
/* the display loop and loop for polling the shared segment */ 
whi | e (TRUE) 

{ 


/* make an outgoing message */ 
strepy(out going, ”PROG2 ORIGINATED MESSAGE: "); 


count = count + 1l; 
outgoingl[0] = count; 
noutgoing = strlen(outgoing); 
outgoing2[0] = count; 


/* is there data in the shared segment? */ 
if(receiver has, data(&remotemaclhnine2)) 


| 


type received - received type(&remotemachine2); 


printf("The message received by PROG2 is of type %c An", 
type received). 


switch (type_received) 


| 
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case CHARACTER_ARRAY_ TYPE: 


elements received = number_received(&remotemachine2); 


printf("The message received by PROG2 is %d elements long!\n", 
elements_received); 


read_characters(&remotemachine2 ,mybuf fer, 
elements_received); 
break; 


case INTEGER_TYPE: 
read_integer(S%remotemachine2,mybufferl); 
break; 


case FLOAT_TYPE: 
read_float(&remotemachine2,mybuffer2); 
break; 


/* at this point in the program, process the received data...*/ 
printf("PROG2 has received the following data:\n"); 


switch (type_received) 


| 
case CHARACTER ARRAY TYPE: 


for(120; i « elements, received; i421) 


| 
printf("%c" mybuffer[i]); 


break; 
case INTEGER TYPE: 


printf("%d" , mybufferl[0]); 
break; 


case FLOAT_TYPE: 
printf("%f"  mybuffer2[0]); 
break; 


printf("\n"); 


/* at this point, we would look at our system and see if we needed 
to send data. Instead, I will check if the sender is free. 
If the sender is free, I will send one of three messages */ 
if(sender is free(&remotemachinel)) 


{ 
1f((j % 3) == 0) 
write_characters(&remotemachinel ,outgoing,nout going); 


/* wait until message sent before attempting to send another */ 
while( !sender is free(&remotemachinel) ) /* do nothing printf("2")*/ 


if((j % 3) == 1) 
write_integer(&remotemachinel,outgoingl); 


/* wait until message sent before attempting to send another */ 
while( !sender_is_free(&remotemachinel) ) /* do nothing printf("3")*/ 


if((j % 3) == 2) 


write float(&remotemachinel,outgoing2); 


/* wait until message sent before continuing */ 
while( !sender_is_free(&remotemachinel) ) /* do nothing printf("4")*/ 


++]: 
) 


else 


| 
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/* assume socket connection broken */ 
printf("Sender wasn't free! Terminating...\n°%); 
break; 
| 


} /* endif while TRUE */ 


[get rid of the path to the other machine... 7 
deletemachinepath(&remotemachine2) ; 
deletemachinepath(&remotemachinel); 
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5. rmshare.c 


a. Calling Protocols 
This is a stand-alone utility. It will remove all shared memory segments owned 


by the user. By command line argument, selective segments can be removed. 


b. Code and Description 


We He He He de ode e He e de ke ale nc ate oe He fe fe oe fee He He oe ae ate ode oh e ae oe e ade Hee fe he he He oe ode oe oe oe oe oe oe oe ode e e ke e al oe oe oe oe ke ok oe ode ee Hee ee ee eK a 


TITLE : Inter-Computer Communication Package 
MODULE : rmshare.c 
VERSION: 1.0 
DATE : 25 February 1988 
AUTHOR : Theodore H. Barrow 
IAA AA III III IRR III RIO IO IAA RI II IRR RIO II IA III RIA RAI AIA IRIS AI ARR RR 
HISTORY: 
VERSION: 1.0 
DATE : 25 February 1988 
AUTHOR : Theodore H. Barrow 


DESC. : Removes shared memory segments identified on conmand line. 


* * * * x * © %* * Xx t %* i+ x» x” H x %* 0E X %* + OF 


| 
»* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
+ 
* 
x e oie ode ade ade e e le ade je oe oe ode oe e le le e e a fe oe oe oe de He le He eae He e e ade ade ae le e ae ale de He He ee ode oe e e a e e He He e e a e oe oe oe oe oe o e He He He e ae He He ee He 
* 
* 
* 


* 

RECORD OF CHANGES : 

* 

*Version* Date * Author £ * Affected *Reqd* 
5 A Change Description * Modules tVers"* 
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#include <errno.h> 
#include <sys/sysmacros .h> 
#include <stdio.h> 
#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/shm.h> 
#include <gl.hl> 


/* The following defines will have to be modified for different machines 
but one of the underlying shared memory attachment mechanisms should 
work for any system V implementation. */ 

define IRISAD 1 

define 1IRIS3000 2 


#1fdef FLAT 

#define MACHINE  IRISAD 
#else 

#define MACHINE  IRIS3000 
#endif 


extern int errno: 
main( argc, argv ) 


int argc; /* argument count */ 
char *argv[]; /* pointers to the passed in arguments */ 


| 


itt DUM 
int last S 1000: 
key thi; 

int shmid; 
keyctukey- 


static struct shmid ds buffer; 


/* set the number of shared memory keys to remove */ 
if(argc » 1) 
| 


for( i=first; i<arge; i++ ) 


key = atoi( argv[i] ); 
if( (shmid = shniget( key, 0, 0)) == -1 ) 
{ 


if( errno != ENOENT ) 
{ 


} 
| 


else 


| 


write error( shmid, key, errno ); 


if( shmctl( shmid, IPC RMID, &buffer == -1 ) 
| 


write error( shmid, key, errno ); 


else 
write done( shmid, key ); 
) /* if( (shmid = shmget( i, 0, 0 )) == -1 ) */ 
OO 


else 
{ 
for( isfirst; i<last; i++ ) 
if( (shmid = shmget( i, 0, 0)) == -l ) 
{ 


if( errno != ENOENT ) 
| 


write_error( shmid, i, errno ); 
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} 


else 


if( shmet!( shmid, IPC RMID, &buffer ) 


—— ) 
| 
E me co (Ss OIM. errno9 
| 
EG 
write done( shmid, 1 ); 
]) /* if( (shmid = shmget( i, 0, 0 )) == -1 ) */ 
lx bor */ 


printf( "\nCompleted.\n" ); 
Iu maim) */ 


write_error( shmid, key, error ) 
int shmid; 


Key t key: 


int error; 


| 


printf( "\nShared Memory ID %d (key %d) caused error %d.", 
shmid, key, error ); 


IN Write error() */ 


write_done( shmid, key ) 
int shmid; 
key_t key; 


{ 
printf( “\nShared Memory ID %d (key %d) removed.", shmid, key ); 


|] /* write done() */ 
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6. testshare.c 


a. Calling Protocols 
This is a stand-alone utility. It will print current parameters for all active 
shared memory segments. By command line argument, selective segments can be 


printed. 


b. Code and Description 


We We Me He e e e al ol e k k ak ade k k e e k e k k ak k ade k ee ee e e de k e e de k ak k e k de k e k ak k e de e e e de oe ie ie e k k k e e k k k k k k k k k e e a de 


TITLE : Inter-Computer Communication Package 
MODULE : testshare.c 
VERSION: 1.0 
DATE : 25 February 1988 
AUTHOR : Theodore H. Barrow 
3ILICACIO ICAO IO RCICICIORIUROIUROROR ak ae ake ae ak ake ak ake ak ake Ae ak ae a ae ke a ak ake aE ake ak ak ake ak ake ak ae ak ae ake ak ae ake ae ak ae ake ae kE ake ak ake ae ake a ak E ak ak akea kkk R k 
HISTORY: 
VERSION: 1.0 
DATE : 25 February 1988 
AUTHOR : Theodore H. Barrow 


DESC. : Determines which shmid values are used and what their 
parameters are. 


E E & * + Xx Xx + +* + X HF +* + FE %* + + OH HH X + 


We Me He He He He He e e ode e de k e e a ae k e e oe e e e e e e le k e e k e e k e de e e ne ke k k k k ke k e de e k ak he ee eee ee ee e k e de k k e he ee ee ee 


3 0 3 #2 * Xx %* E E E Xx x Xx HH HH HH H %* 0X x %*% E E XT- 


* 

RECORD OF CHANGES s 

x. 

*Version* Date * Author * * Affected *Reqd* 
s 5 Change Description si Modules *Vers* 
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* * * * x * x 
* * x * x 
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#iuctude <errno.h> 
include <sys/sysmacros.h> 
fiuclude <stdio.h> 
#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/shm.h> 
#include <gl.h> 


/* The following defines will have to be modified for different machines 
but one of the underlying shared memory attachment mechanisms should 
work for any system V implementation. */ 

#define IRIS4D l 

#define IRIS3000 2 


#ifdef FLAT 

#define MACHINE IRIS4D 
Helse 

Hdefine MACHINE IRIS3000 
#endif 


extern int errno; 


main( ) 

( 
tit first = Í; 
int last = 1000: 
int i; 


int shmid: 
for( i=first; i<last: i++ ) 


if( (shmid = shmget( i, 0, 0)) == -1 ) 
| 

if( errno != ENOENT ) 

{ 


} 


write_error( shmid, i, errno ); 


else 
| 
if( write struct( shmid ) == -1 ) 
write_error( shmid, i, errno ); 
| /* if( (shmid = shmget( i, 0, O )) == -1 ) */ 
METAS 


printf( "\nCompleted.\n" ); 


Ja. marn(» */ 


write error( shmid, key, error ) 
int shmid; 
key t key: 
int error; 


| 
printf( "\nShared Memory ID %d (key %d) caused error %d.", 
shmid, key, error ); 
Ie *cwpywte-cerror() "/ 


struct shmid ds *get struct( shmid ) 
iut shmid ; 


static struct shmid ds buffer; 


if( shmetl( shmid, IPC_STAT, &buffer ) == -1 ) 
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| 


PES 
return( &buffer ); 


return( (struct shmid_ds *)-1 ); 


} /* get struct)" 
write_struct( shmid ) 
int shmid: 

{ 


struct shmid ds *buf; 


if( (int)(buf = get_struct( shmid )) == -1 ) 
return( (int)buf ); 


printf( "\nShared Memory ID %d has the following structure:”, shmid ); 


printf( "\n shm_perm has the following structure:" ); 

printf( "\n cuid is %d.", buf->shm_perm.cuid ); 

printf( "\n cgid is %d.", buf->shm_perm.cgid ); 

printf( "\n uid is %d.", buf->shm_perm.uid ); 

printf( "*n gid is %d.", buf->shm_perm.gid ); 

printf( "An mode is %o.”, buf->shm_perm.mode ); 

printf( "An seq is %d.", buf->shm_perm.seq ); 

printf( "\n key is %d.", buf->shm_perni.key ); 

printf( "An shm_segsz is %d or %x.”, buf->shm_segsz, buf->shm_segsz ); 
printf( "An shm_reg is a structure incompletely defined in region.h!" ); 


printf( "An shm_lpid is %d.", buf->shm_lpid ); 
printf( "\n shm_cpid is %d.”, buf->shm_cpid ); 
printf( "An shm_nattch is %d.”, buf->shm_nattch ); 
printf( "An shm_cnattch is %d.”, buf->shm_cnattch ); 
printf( "An shm atime is ?d.", buf->shm_atime ); 
printf( “An shm_dtime is %d.”, buf->shm_dtime ); 
printf( "An shm_ctime is %d.”, buf->shm_segsz ); 


return( O ); 


) /* write. struct() */ 
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